Skip to content

Rebase on top of current Rust LLVM fork #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 10,000 commits into from
Closed

Conversation

dylanmckay
Copy link
Member

Dylan McKay and others added 30 commits January 20, 2017 13:12
…t honor the recently added file-based API

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292731 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r291858 | eugenis | 2017-01-12 15:03:03 -0800 (Thu, 12 Jan 2017) | 1 line

[asan] Refactor instrumentation of globals.
------------------------------------------------------------------------

------------------------------------------------------------------------
r291859 | eugenis | 2017-01-12 15:26:20 -0800 (Thu, 12 Jan 2017) | 6 lines

[asan] Don't overalign global metadata.

Other than on COFF with incremental linking, global metadata should
not need any extra alignment.

Differential Revision: https://reviews.llvm.org/D28628
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292802 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r292583 | dannyb | 2017-01-19 22:38:41 -0800 (Thu, 19 Jan 2017) | 4 lines

NewGVN: Fix PR 31682, an overactive assert.
Part of the assert has been left active for further debugging.
The other part has been turned into a stat for tracking for the
moment.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292810 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r292323 | pzheng | 2017-01-17 17:03:29 -0800 (Tue, 17 Jan 2017) | 9 lines

[test-release.sh] Add Polly to the list of projects

Reviewers: zinob, hans, grosser

Reviewed By: hans, grosser

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D28712
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292831 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r292758 | spatel | 2017-01-22 09:06:12 -0800 (Sun, 22 Jan 2017) | 4 lines

[x86] avoid crashing with illegal vector type (PR31672)

https://llvm.org/bugs/show_bug.cgi?id=31672

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292832 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r292467 | compnerd | 2017-01-18 18:58:46 -0800 (Wed, 18 Jan 2017) | 7 lines

llvm-cxxfilt: filter out invalid manglings

c++filt does not attempt to demangle symbols which do not match its
expected format.  This means that the symbol must start with _Z or ___Z
(block invocation function extension).  Any other symbols are returned
as is.  Note that this is different from the behaviour of __cxa_demangle
which will demangle fragments.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292861 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r291909 | compnerd | 2017-01-13 08:25:33 -0800 (Fri, 13 Jan 2017) | 9 lines

ARM: match GCC's behaviour for builtins

GCC changes the CC between the user-code and the builtins based on the
value of `-target` rather than `-mfloat-abi`.  When a HF target is used,
the VFP variant of the AAPCS CC is used.  Otherwise, the AAPCS variant
is used.  In all cases, the AEABI functions use the AAPCS CC.  Adjust
the calling convention based on the target.

Resolves PR30543!
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292951 91177308-0d34-0410-b5e6-96231b3b80d8
… with side effects) if it has a param with the 'returned' attribute
------------------------------------------------------------------------
r292444 | mkuper | 2017-01-18 15:05:58 -0800 (Wed, 18 Jan 2017) | 7 lines

Revert r291670 because it introduces a crash.

r291670 doesn't crash on the original testcase from PR31589,
but it crashes on a slightly more complex one.

PR31589 has the new reproducer.

------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293070 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r293025 | ahatanak | 2017-01-24 22:21:51 -0800 (Tue, 24 Jan 2017) | 29 lines

[SimplifyCFG] Do not sink and merge inline-asm instructions.

Conservatively disable sinking and merging inline-asm instructions as doing so
can potentially create arguments that cannot satisfy the inline-asm constraints.

For example, SimplifyCFG used to do the following transformation:

(before)
if.then:
  %0 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 8)
  br label %if.end
if.else:
  %1 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 6)
  br label %if.end

(after)
  %.sink = select i1 %tobool, i32 6, i32 8
  %0 = call i32 asm "rorl $2, $0", "=&r,0,n"(i32 %r6, i32 %.sink)

This would result in a crash in the backend since only immediate integer operands
are permitted for constraint "n".

rdar://problem/30110806

Differential Revision: https://reviews.llvm.org/D29111




------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293074 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r293088 | tnorthover | 2017-01-25 12:58:26 -0800 (Wed, 25 Jan 2017) | 5 lines

SDag: fix how initial loads are formed when splitting vector ops.

Later code expects the vector loads produced to be directly
concatenable, which means we shouldn't pad anything except the last load
produced with UNDEF.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293103 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r292651 | jvesely | 2017-01-20 13:24:26 -0800 (Fri, 20 Jan 2017) | 8 lines

AMDGPU/R600: Serialize vector trunc stores to private AS

Add DUMMY_CHAIN SDNode to denote stores of interest

Bugzilla: https://llvm.org/bugs/show_bug.cgi?id=28915
Bugzilla: https://llvm.org/bugs/show_bug.cgi?id=30411

Differential Revision: https://reviews.llvm.org/D27964
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293118 91177308-0d34-0410-b5e6-96231b3b80d8
…ct lane size (2,4,8 or 16). This prevents i1xN vector constant creation from getting erroneously expanded up to a nonexisting Bool1x128 type.
------------------------------------------------------------------------
r293000 | thomas.stellard | 2017-01-24 17:25:13 -0800 (Tue, 24 Jan 2017) | 15 lines

AMDGPU add support for spilling to a user sgpr pointed buffers

Summary:
This lets you select which sort of spilling you want, either s[0:1] or 64-bit loads from s[0:1].

Patch By: Dave Airlie

Reviewers: nhaehnle, arsenm, tstellarAMD

Reviewed By: arsenm

Subscribers: mareko, llvm-commits, kzhuravl, wdng, yaxunl, tony-tye

Differential Revision: https://reviews.llvm.org/D25428

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293240 91177308-0d34-0410-b5e6-96231b3b80d8
…etadataLoader::MetadataLoaderImpl::parseOneMetadata.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293292 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r292516 | rserge | 2017-01-19 12:24:23 -0800 (Thu, 19 Jan 2017) | 14 lines

[XRay][Arm] Repair XRay table emission on Arm32 and add tests to identify such problem earlier

Summary:
Emission of XRay table was occasionally disabled for Arm32, but this bug was not then detected because earlier (also by mistake) testing of XRay was occasionally disabled on 32-bit Arm targets. This patch should fix that problem and detect such problems in the future.
This patch is one of a series, see also
- https://reviews.llvm.org/D28623

Reviewers: rengolin, dberris

Reviewed By: dberris

Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown

Differential Revision: https://reviews.llvm.org/D28624
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293295 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r292712 | ctopper | 2017-01-20 22:59:35 -0800 (Fri, 20 Jan 2017) | 1 line

[X86] Add test cases that show bad commuting being allowed to create a phsub operation.
------------------------------------------------------------------------

------------------------------------------------------------------------
r292713 | ctopper | 2017-01-20 22:59:38 -0800 (Fri, 20 Jan 2017) | 3 lines

[X86] Don't allow commuting to form phsub operations.

Fixes PR31714.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293299 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r293259 | compnerd | 2017-01-26 19:41:53 -0800 (Thu, 26 Jan 2017) | 11 lines

ARM: fix vectorized division on WoA

The Windows on ARM target uses custom division for normal division as
the backend needs to insert division-by-zero checks.  However, it is
designed to only handle non-vectorized division.  ARM has custom
lowering for vectorized division as that can avoid loading registers
with the values and invoke a division routine for each one, preferring
to lower using NEON instructions.  Fall back to the custom lowering for
the NEON instructions if we encounter a vectorized division.

Resolves PR31778!
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293306 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r292472 | arsenm | 2017-01-18 22:04:12 -0800 (Wed, 18 Jan 2017) | 5 lines

AMDGPU: Remove modifiers from v_div_scale_*

They seem to produce nonsense results when used.

This should be applied to the release branch.
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@293317 91177308-0d34-0410-b5e6-96231b3b80d8
chandlerc and others added 27 commits July 1, 2017 21:58
the nonnull attribute distinct from rewriting it into an assume.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306358 91177308-0d34-0410-b5e6-96231b3b80d8
This is based heavily on the work done ni D34285. I mostly wanted to do
test cleanup for the author to save them some time, but I had a really
hard time understanding why it was so hard to write better test cases
for these issues.

The problem is that because SROA does a second rewrite of the loads and
because we *don't* propagate !nonnull for non-pointer loads, we first
introduced invalid !nonnull metadata and then stripped it back off just
in time to avoid most ways of this PR manifesting. Moving to the more
careful utility only fixes this by changing the predicate to look at the
new load's type rather than the target type. However, that *does* fix
the bug, and the utility is much nicer including adding range metadata
to model the nonnull property after a conversion to an integer.

However, we have bigger problems because we don't actually propagate
*range* metadata, and the utility to do this extracted from instcombine
isn't really in good shape to do this currently. It *only* handles the
case of copying range metadata from an integer load to a pointer load.
It doesn't even handle the trivial cases of propagating from one integer
load to another when they are the same width! This utility will need to
be beefed up prior to using in this location to get the metadata to
fully survive.

And even then, we need to go and teach things to turn the range metadata
into an assume the way we do with nonnull so that when we *promote* an
integer we don't lose the information.

All of this will require a new test case that looks kind-of like
`preserve-nonnull.ll` does here but focuses on range metadata. It will
also likely require more testing because it needs to correctly handle
changes to the integer width, especially as SROA actively tries to
change the integer width!

Last but not least, I'm a little worried about hooking the range
metadata up here because the instcombine logic for converting from
a range metadata *to* a nonnull metadata node seems broken in the face
of non-zero address spaces where null is not mapped to the integer `0`.
So that probably needs to get fixed with test cases both in SROA and in
instcombine to cover it.

But this *does* extract the core PR fix from D34285 of preventing the
!nonnull metadata from being propagated in a broken state just long
enough to feed into promotion and crash value tracking.

On D34285 there is some discussion of zero-extend handling because it
isn't necessary. First, the new load size covers all of the non-undef
(ie, possibly initialized) bits. This may even extend past the original
alloca if loading those bits could produce valid data. The only way its
valid for us to zero-extend an integer load in SROA is if the original
code had a zero extend or those bits were undef. And we get to assume
things like undef *never* satifies nonnull, so non undef bits can
participate here. No need to special case the zero-extend handling, it
just falls out correctly.

The original credit goes to Ariel Ben-Yehuda! I'm mostly landing this to
save a few rounds of trivial edits fixing style issues and test case
formulation.

Differental Revision: D34285

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306379 91177308-0d34-0410-b5e6-96231b3b80d8
Preserve nonnull metadata on Loads through SROA & mem2reg
This makes sure we get the same redefinition rules regardless of who
is printing (asm parser, codegen) and to what (asm, obj).

This fixes an unintentional regression in r293936.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294752 91177308-0d34-0410-b5e6-96231b3b80d8
Move some error handling down to MCStreamer.
It caused the register to later be dead, which would trigger a verifier
error.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301368 91177308-0d34-0410-b5e6-96231b3b80d8
It is sufficient to skip emission of these arguments as we have nothing
to actually pass through the function call.

The AVR-GCC reference has nothing to say about zero-sized arguments,
presumably because C/C++ doesn't support them. This means we don't have
to worry about ABI differences.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294119 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Authored by Florian Zeitz.

This implements the missing stacksave/stackrestore intrinsics via expansion.

Output of `llc -O0 -march=avr ~/devel/llvm/test/CodeGen/Generic/stacksave-restore.ll` for sanity checking (comments mine):

```
	.text
	.file	".../llvm/test/CodeGen/Generic/stacksave-restore.ll"
	.globl	test
	.p2align	1
	.type	test,@function
test:                                   ; @test
; BB#0:
	push	r28
	push	r29

	in	r28, 61
	in	r29, 62
	sbiw	r28, 4
	in	r0, 63
	cli
	out	62, r29
	out	63, r0
	out	61, r28

	in	r18, 61
	in	r19, 62

	mov	r20, r22
	mov	r21, r23

	in	r30, 61
	in	r31, 62

	lsl	r22
	rol	r23
	lsl	r22
	rol	r23
	in	r26, 61
	in	r27, 62
	sub	r26, r22
	sbc	r27, r23
	andi	r26, 252
	in	r0, 63
	cli
	out	62, r27
	out	63, r0
	out	61, r26

	in	r0, 63
	cli
	out	62, r31
	out	63, r0
	out	61, r30

	in	r30, 61
	in	r31, 62
	sub	r30, r22
	sbc	r31, r23
	andi	r30, 252
	in	r0, 63
	cli
	out	62, r31
	out	63, r0
	out	61, r30

	std	Y+3, r24                ; 2-byte Folded Spill
	std	Y+4, r25                ; 2-byte Folded Spill

	mov	r24, r26
	mov	r25, r27

	in	r0, 63
	cli
	out	62, r19
	out	63, r0
	out	61, r18

	std	Y+1, r20                ; 2-byte Folded Spill
	std	Y+2, r21                ; 2-byte Folded Spill

	adiw	r28, 4
	in	r0, 63
	cli
	out	62, r29
	out	63, r0
	out	61, r28

	pop	r29
	pop	r28
	ret
.Lfunc_end0:
	.size	test, .Lfunc_end0-test
```

Reviewers: dylanmckay

Reviewed By: dylanmckay

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D29553

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294146 91177308-0d34-0410-b5e6-96231b3b80d8
…offset

Before this, the LDS/STS instructions would have their opcodes
overwritten while linking.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301782 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us do bit rotations of variable amount.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301794 91177308-0d34-0410-b5e6-96231b3b80d8
Because it was a callee-saved register, we automatically generated code
to spill and unspill its original value so that it is restored after the
function returns.

The problem is that this code was being generated before the epilogue.
The epilogue itself uses the Y register, which could be prematurely
restored by the CSR restoration process.

This removes R29R28 from the CSR list and changes the prologue/epilogue
code to handle it explicitly.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301887 91177308-0d34-0410-b5e6-96231b3b80d8
A recent commit I made made it so that we only did this for signal or
interrupt handlers. This broke normal functions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301893 91177308-0d34-0410-b5e6-96231b3b80d8
… same spot

Contributed by Dr. Gergő Érdi.

Fixes a bug.

Raised from (avr-rust/rust-legacy-fork#49).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302973 91177308-0d34-0410-b5e6-96231b3b80d8
When generating code for a shift loop, check the shift
 amount against the literal value 0, not R0

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304284 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: CPI does not read the status register, but only writes it.

Reviewers: dylanmckay

Reviewed By: dylanmckay

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D33223

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304116 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, if a basic block ended with a FRMIDX instruction, we would
end up doing something like this.

*std::next(MBB.end())

Which would hit an error:

"Assertion `!NodePtr->isKnownSentinel()' failed."
Patch by Carl Peto.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307888 91177308-0d34-0410-b5e6-96231b3b80d8
Also enables '__do_clear_bss'.

These functions are automaticalled called by the CRT if they are
declared.

We need these to be called otherwise RAM will start completely
uninitialised, even though we need to copy RAM variables from progmem to
RAM.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312905 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the issue (rust-lang#75) with floating-point comparisons generating broken code.
By default, LLVM assumes these comparisons return 32-bit values, but ours are 8-bit.
@dylanmckay
Copy link
Member Author

The base of this PR is master, which is not quite right, so this PR isn't very useful

@dylanmckay dylanmckay closed this Sep 24, 2017
@shepmaster
Copy link
Member

so this PR isn't very useful

You can't merge in a rebase, anyway 😸

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.