| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 237483
|
|
|
|
| |
llvm-svn: 237481
|
|
|
|
|
|
|
|
|
| |
Other pieces of CodeGen want to negate frame object offsets to account
for architectures where the stack grows down. Our object is a pseudo
object so it's offset doesn't matter. However, we shouldn't choose an
offset which results in undefined behavior if you negate it.
llvm-svn: 237474
|
|
|
|
|
|
| |
s/InitMCCodeGenInfo/initMCCodeGenInfo/
llvm-svn: 237471
|
|
|
|
|
|
| |
s/EncodeInstruction/encodeInstruction/
llvm-svn: 237469
|
|
|
|
|
|
| |
s/MCFixup::Create/MCFixup::create/
llvm-svn: 237468
|
|
|
|
|
|
|
| |
The new [SU]{MIN,MAX} SDNodes can be lowered directly to instructions for
most NEON datatypes - the big exclusion being v2i64.
llvm-svn: 237455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
XCore doesn't seem to have any additional constraints. Therefore remove
the target hook.
No functional change intended.
Reviewers: friedgold
Reviewed By: friedgold
Subscribers: friedgold, llvm-commits
Differential Revision: http://reviews.llvm.org/D8921
llvm-svn: 237442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
To maintain compatibility with GAS, we need to stop treating negative 32-bit immediates as 64-bit values when expanding LI/DLI.
This currently happens because of sign extension.
To do this we need to choose the 32-bit value expansion for values which use their upper 33 bits only for sign extension (i.e. no 0's, only 1's).
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8662
llvm-svn: 237428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of doing that, create a temporary copy of MCTargetOptions and reset its
SanitizeAddress field based on the function's attribute every time an InlineAsm
instruction is emitted in AsmPrinter::EmitInlineAsm.
This is part of the work to remove TargetMachine::resetTargetOptions (the FIXME
added to TargetMachine.cpp in r236009 explains why this function has to be
removed).
Differential Revision: http://reviews.llvm.org/D9570
llvm-svn: 237412
|
|
|
|
| |
llvm-svn: 237398
|
|
|
|
|
|
|
|
|
| |
The induction variable in the vectorized loop wasn't
recognized properly, so a hardware loop wasn't generated.
Differential Revision: http://reviews.llvm.org/D9722
llvm-svn: 237388
|
|
|
|
|
|
|
|
|
|
|
| |
After converting a loop to a hardware loop, the pass should remove
any unnecessary instructions from the old compare-and-branch
code. This patch removes a dead constant assignment that was
used in the compare instruction.
Differential Revision: http://reviews.llvm.org/D9720
llvm-svn: 237373
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9752
llvm-svn: 237367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When used, ".set nomacro" causes warning messages to be reported when we expand pseudo-instructions to multiple machine instructions.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9564
llvm-svn: 237366
|
|
|
|
|
|
|
|
| |
If the loop trip count may underflow or wrap, the compiler should
not generate a hardware loop since the trip count will be
incorrect.
llvm-svn: 237365
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9563
llvm-svn: 237363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When we are trying to fill the delay slot of a call instruction, we must avoid
filler instructions that use the $ra register. This fixes the test
MultiSource/Applications/JM/lencod when we enable the forward delay slot filler.
Reviewers: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9670
llvm-svn: 237362
|
|
|
|
|
|
| |
No longer breaks SPEC2000/2006
llvm-svn: 237361
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9295
llvm-svn: 237356
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we only pass the necessary operands, we don't have to determine the position of the symbol operand when entering expandLoadAddressSym().
This simplifies the expandLoadAddressSym() code.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9291
llvm-svn: 237355
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: echristo
Subscribers: llvm-commits
Follow-up to: http://reviews.llvm.org/D8496#158595
Relates to: http://reviews.llvm.org/rL235089
llvm-svn: 237354
|
|
|
|
|
|
|
|
| |
i1 type is a legal type on AVX-512 and can be passed as parameter or return value.
i1 is promoted to i8 on return and to i32 for call arguments (i8 is also promoted to i32 here).
The result code is similar to the previous X86 targets, where i1 is allways promoted to i8.
llvm-svn: 237350
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9110
llvm-svn: 237310
|
|
|
|
|
|
|
|
| |
There's no need to manually pass modifier strings around to tell an operand how
to print now, that information is encoded in the operand itself since the MC
layer came along.
llvm-svn: 237295
|
|
|
|
|
|
|
|
| |
We were creating and propagating two separate indices for each jump table (from
back in the mists of time). However, the generic index used by other backends
is sufficient to emit a unique symbol so this was unneeded.
llvm-svn: 237294
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous logic mixed 2 separate questions:
+ Can we form a TBB/TBH instruction?
+ Can we remove the jump-table calculation before it?
It then performed a bunch of random tests on the instructions earlier in the
basic block, which were probably sufficient to answer 2 but only because of the
very limited ways in which a t2BR_JT can actually be created.
For example there's no reason to expect the LeaInst to define the same base
register as the following indexing calulation. In practice this means we might
have missed opportunities to form TBB/TBH, in theory you could end up
misidentifying a sequence and removing the wrong LEA:
%R1 = t2LEApcrelJT ...
%R2 = t2LEApcrelJT ...
<... using and killing %R2 ...>
%R2 = t2ADDr %R1, $Ridx
Before we would have looked for an LEA defining %R2 and found the wrong one. We
just got lucky that jump table setup was (almost?) always confined to a single
basic block and there was only one jump table per block.
llvm-svn: 237293
|
|
|
|
|
|
| |
MCOperand::Create*() methods renamed to MCOperand::create*().
llvm-svn: 237275
|
|
|
|
|
|
|
|
| |
loop1 is for the outer loop and loop0 is for the inner loop.
Differential Revision: http://reviews.llvm.org/D9680
llvm-svn: 237266
|
|
|
|
|
|
|
|
|
|
|
| |
Some compilers warn about using the ternary operator with an unsigned variable
and enum.
I haven't seen this trigger in the llvm.org buildbots yet, but it probably will
at some point.
Reported by Daniel Sanders.
llvm-svn: 237262
|
|
|
|
|
|
|
|
|
| |
The hardware loop pass should try to generate a hardware loop
instruction when the original loop has a critical edge.
Differential Revision: http://reviews.llvm.org/D9678
llvm-svn: 237258
|
|
|
|
|
|
|
|
| |
This patch implements CLO and CLZ instructions using mapping.
Differential Revision: http://reviews.llvm.org/D8553
llvm-svn: 237257
|
|
|
|
|
|
| |
SPEC2000/2006
llvm-svn: 237256
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: A side-effect of this is that LA gains proper handling of unsigned and positive signed 16-bit immediates and more accurate error messages.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9290
llvm-svn: 237255
|
|
|
|
| |
llvm-svn: 237247
|
|
|
|
|
|
|
| |
The buildbots are still not satisfied.
MIPS and ARM are failing (even though at least MIPS was expected to pass).
llvm-svn: 237245
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, subtarget features were a bitfield with the underlying type being uint64_t.
Since several targets (X86 and ARM, in particular) have hit or were very close to hitting this bound, switching the features to use a bitset.
No functional change.
The first two times this was committed (r229831, r233055), it caused several buildbot failures.
At least some of the ARM and MIPS ones were due to gcc/binutils issues, and should now be fixed.
llvm-svn: 237234
|
|
|
|
|
|
| |
added a bunch of encoding tests.
llvm-svn: 237232
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds two new parameters to the statepoint intrinsic, `i64 id`
and `i32 num_patch_bytes`. `id` gets propagated to the ID field
in the generated StackMap section. If the `num_patch_bytes` is
non-zero then the statepoint is lowered to `num_patch_bytes` bytes of
nops instead of a call (the spill and reload code remains unchanged).
A non-zero `num_patch_bytes` is useful in situations where a language
runtime requires complete control over how a call is lowered.
This change brings statepoints one step closer to patchpoints. With
some additional work (that is not part of this patch) it should be
possible to get rid of `TargetOpcode::STATEPOINT` altogether.
PlaceSafepoints generates `statepoint` wrappers with `id` set to
`0xABCDEF00` (the old default value for the ID reported in the stackmap)
and `num_patch_bytes` set to `0`. This can be made more sophisticated
later.
Reviewers: reames, pgavlin, swaroop.sridhar, AndyAyers
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9546
llvm-svn: 237214
|
|
|
|
|
|
|
| |
This commit broke an x86 test and the bots have been broken for well
over an hour now so I'm just reverting.
llvm-svn: 237210
|
|
|
|
|
|
|
|
| |
Reverting until I figure out the new lit failures.
This reverts commit r237179.
llvm-svn: 237189
|
|
|
|
|
|
|
|
|
|
| |
They do more harm than good when used in the MachineScheduler as they
tend to take preference to register pressure minimsation which is more
important for swift.
Differential Revision: http://reviews.llvm.org/D9718
llvm-svn: 237179
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This rule was always in the old SysV i386 ABI docs and the new ones that
H.J. Lu has put together, but we never noticed:
EAX scratch register; also used to return integer and pointer values
from functions; also stores the address of a returned struct or union
Fixes PR23491.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9715
llvm-svn: 237175
|
|
|
|
| |
llvm-svn: 237165
|
|
|
|
|
|
|
|
|
|
|
|
| |
AMDGPU::SI_SPILL_V96_RESTORE was missing from a switch statement, which
caused the srsrc and soffset register to not be set correctly.
This commit replaces the switch statement with a SITargetInfo query
to make sure all spill instructions are covered.
Differential Revision: http://reviews.llvm.org/D9582
llvm-svn: 237164
|
|
|
|
|
|
|
|
| |
This patch implements SELEQZ and SELNEZ instructions using mapping.
Differential Revision: http://reviews.llvm.org/D8497
llvm-svn: 237158
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Mips, frame pointer points to the same side of the frame as the stack
pointer. This function is used to decide where to put register scavenging
spill slot. So far, it was put on the wrong side of the frame, and thus it
was too far away from $fp when frame was larger than 2^15 bytes.
Patch by Vladimir Radosavljevic.
http://reviews.llvm.org/D8895
llvm-svn: 237153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Spilling can insert instructions almost anywhere, and this can mess
up control flow lowering in a multitude of ways, due to instruction
reordering. Let's sort this out the easy way: never spill registers
involved with control flow, i.e. saved EXEC masks.
Unfortunately, this does not work at all with optimizations disabled,
as the register allocator ignores spill weights. This should be
addressed in a future commit.
The test was reduced from the "stacks" shader of [1]. Some issues
trigger the machine verifier while another one is checked manually.
[1] http://madebyevan.com/webgl-path-tracing/
v2: only insert pass with optimizations enabled, merge test runs.
Patch by: Grigori Goronzy
llvm-svn: 237152
|
|
|
|
| |
llvm-svn: 237144
|
|
|
|
|
|
|
|
| |
We had code to do this in SIRegisterInfo::eliminateFrameIndex(), but
it is easier to just change the definition of SI_SPILL_S32_RESTORE to
only allow numbered sgprs.
llvm-svn: 237143
|