| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
SimplifyLibCalls utility by sinking it into the specific call part of
the combiner.
This will avoid us needing to do any contortions to build this object in
a subsequent refactoring I'm doing and seems generally better factored.
We don't need this utility everywhere and it carries no interesting
state so we might as well build it on demand.
llvm-svn: 226654
|
| |
|
|
|
|
| |
instructions for mips r6 it crashes as the access to operands array is out of range. This patch adds dedicated decoder method that properly handles decoding of these instructions.
llvm-svn: 226652
|
| |
|
|
|
|
| |
patterns. I think it actually went i32->iPtr->i32 in some of these cases.
llvm-svn: 226647
|
| |
|
|
| |
llvm-svn: 226646
|
| |
|
|
|
|
| |
This makes the assembler check their size and removes a hack from the disassembler to avoid sign extending the immediate.
llvm-svn: 226645
|
| |
|
|
|
|
| |
cmpss/cmpsd/cmpps/cmppd.
llvm-svn: 226642
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
a more direct approach: a type-erased glorified function pointer. Now we
can pass a function pointer into this for the easy case and we can even
pass a lambda into it in the interesting case in the instruction
combiner.
I'll be using this shortly to simplify the interfaces to InstCombiner,
but this helps pave the way and seems like a better design for the
libcall simplifier utility.
llvm-svn: 226640
|
| |
|
|
|
|
| |
elements and the ordering is sane and cleanup the accessors.
llvm-svn: 226627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a small internal pass which runs the InstCombiner over
a function. This is the hard part of porting InstCombine to the new pass
manager, as at this point none of the code in InstCombine has access to
a Pass object any longer.
The resulting interface for the InstCombiner is pretty terrible. I'm not
planning on leaving it that way. The key thing missing is that we need
to separate the worklist from the combiner a touch more. Once that's
done, it should be possible for *any* part of LLVM to just create
a worklist with instructions, populate it, and then combine it until
empty. The pass will just be the (obvious and important) special case of
doing that for an entire function body.
For now, this is the first increment of factoring to make all of this
work.
llvm-svn: 226618
|
| |
|
|
|
|
| |
Follow-up to r226588.
llvm-svn: 226616
|
| |
|
|
|
|
|
|
|
|
| |
don't get muddied up by formatting changes.
Some of these don't really seem like improvements to me, but they also
don't seem any worse and I care much more about not formatting them
manually than I do about the particular formatting. =]
llvm-svn: 226610
|
| |
|
|
| |
llvm-svn: 226606
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses part of llvm.org/PR22262. Specifically, it prevents
considering the densities of sub-ranges that have fewer than
TLI.getMinimumJumpTableEntries() elements. Those densities won't help
jump tables.
This is not a complete solution but works around the most pressing
issue.
Review: http://reviews.llvm.org/D7070
llvm-svn: 226600
|
| |
|
|
|
|
|
|
|
|
| |
With the appropriate Verifier changes, exactracting the result out of a
statepoint wrapping a vararg function crashes. However, a void vararg
function works fine: commit this first step.
Differential Revision: http://reviews.llvm.org/D7071
llvm-svn: 226599
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reapplies r225379.
ChangeLog:
- The assertion that this commit previously ran into about the inability
to handle indirect variables has since been removed and the backend
can handle this now.
- Testcases were upgrade to the new MDLocation format.
- Instead of keeping a DebugDeclares map, we now use
llvm::FindAllocaDbgDeclare().
Original commit message follows.
Debug info: Teach SROA how to update debug info for fragmented variables.
This allows us to generate debug info for extremely advanced code such as
typedef struct { long int a; int b;} S;
int foo(S s) {
return s.b;
}
which at -O1 on x86_64 is codegen'd into
define i32 @foo(i64 %s.coerce0, i32 %s.coerce1) #0 {
ret i32 %s.coerce1, !dbg !24
}
with this patch we emit the following debug info for this
TAG_formal_parameter [3]
AT_location( 0x00000000
0x0000000000000000 - 0x0000000000000006: rdi, piece 0x00000008, rsi, piece 0x00000004
0x0000000000000006 - 0x0000000000000008: rdi, piece 0x00000008, rax, piece 0x00000004 )
AT_name( "s" )
AT_decl_file( "/Volumes/Data/llvm/_build.ninja.release/test.c" )
Thanks to chandlerc, dblaikie, and echristo for their feedback on all
previous iterations of this patch!
llvm-svn: 226598
|
| |
|
|
|
|
|
| |
This is disabled by default, but can be enabled with the subtarget
feature: 'vgpr-spilling'
llvm-svn: 226597
|
| |
|
|
| |
llvm-svn: 226596
|
| |
|
|
| |
llvm-svn: 226595
|
| |
|
|
|
|
| |
prior to refactoring it.
llvm-svn: 226594
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConstantArrays constructed during linking can cause quadratic memory
explosion. An example is the ConstantArrays constructed when linking in
GlobalVariables with appending linkage.
Releasing all unused constants can cause a 20% LTO compile-time
slowdown for a large application. So this commit releases unused ConstantArrays
only.
rdar://19040716. It reduces memory footprint from 20+G to 6+G.
llvm-svn: 226592
|
| |
|
|
| |
llvm-svn: 226591
|
| |
|
|
| |
llvm-svn: 226588
|
| |
|
|
|
|
|
|
| |
We were passing the scratch buffer address to the shaders via user sgprs,
but now we use external symbols and have the driver patch the shader
using reloc information.
llvm-svn: 226586
|
| |
|
|
|
|
|
| |
This allows us to re-use the same register for the scratch offset
when accessing large private arrays.
llvm-svn: 226585
|
| |
|
|
|
|
|
|
| |
We don't have a good way of legalizing this if the frame index offset
is more than the 12-bits, which is size of MUBUF's offset field, so
now we store the frame index in the vaddr field.
llvm-svn: 226584
|
| |
|
|
|
|
|
| |
Now that we have our own custom register operand types, we need
to handle them in the verifiier.
llvm-svn: 226583
|
| |
|
|
| |
llvm-svn: 226581
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement microMIPS 16-bit unconditional branch instruction B.
Implemented 16-bit microMIPS unconditional instruction has real name B16, and
B is an alias which expands to either B16 or BEQ according to the rules:
b 256 --> b16 256 # R_MICROMIPS_PC10_S1
b 12256 --> beq $zero, $zero, 12256 # R_MICROMIPS_PC16_S1
b label --> beq $zero, $zero, label # R_MICROMIPS_PC16_S1
Differential Revision: http://reviews.llvm.org/D3514
llvm-svn: 226577
|
| |
|
|
|
|
|
|
|
| |
This commits adds the octeon branch instructions bbit0/bbit032/bbit1/bbit132.
It also includes patterns for instruction selection and test cases.
Reviewed by D. Sanders
llvm-svn: 226573
|
| |
|
|
|
|
|
|
| |
The new code does not create new basic blocks in the case when shadow is a
compile-time constant; it generates either an unconditional __msan_warning
call or nothing instead.
llvm-svn: 226569
|
| |
|
|
|
|
|
|
| |
Reviewers: kcc, samsonov, petarj, eugenis
Differential Revision: http://reviews.llvm.org/D6146
llvm-svn: 226565
|
| |
|
|
|
|
| |
covered by a pattern.
llvm-svn: 226562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
pass and a LoopPrinterPass with the expected associated wiring.
I've added a RUN line to the only test case (!!!) we have that actually
prints loops. Everything seems to be working.
This is somewhat exciting as this is the first analysis using another
analysis to go in for the new pass manager. =D I also believe it is the
last analysis necessary for porting instcombine, but of course I may yet
discover more.
llvm-svn: 226560
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for a fix to llvm.org/PR22262. One of the ideas
here is to first find a good jump table range first and then split
before and after it. Thereby, we don't need to use the
split-based-on-density heuristic at all, which can make the "binary
tree" deteriorate in various cases.
Also some minor cleanups.
No functional changes.
llvm-svn: 226551
|
| |
|
|
|
|
|
|
|
|
|
| |
along with the other analyses.
The most obvious reason why is because eventually I need to separate out
the pass layer from the rest of the instcombiner. However, it is also
probably a compile time win as every query through the pass manager
layer is pretty slow these days.
llvm-svn: 226550
|
| |
|
|
|
|
|
|
|
|
| |
This patch fixes 2 issues in reorderInputsAccordingToOpcode
1) AllSameOpcodeLeft and AllSameOpcodeRight was being calculated incorrectly resulting in code not being vectorized in few cases.
2) Adds logic to reorder operands if we get longer chain of consecutive loads enabling vectorization. Handled the same for cases were we have AltOpcode.
Thanks Michael for inputs and review.
Review: http://reviews.llvm.org/D6677
llvm-svn: 226547
|
| |
|
|
|
|
|
| |
Don't infer COMDAT groups from older bitcode if the target is macho,
it doesn't have COMDATs.
llvm-svn: 226546
|
| |
|
|
|
|
|
| |
This reverts commit r226542, effectively reapplying r226540. This time,
initialize `IsEmpty` in the copy and move constructors as well.
llvm-svn: 226545
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r226540, since I hit an unexpected bot failure [1].
I'll investigate.
[1]: http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/20244
llvm-svn: 226542
|
| |
|
|
|
|
|
|
| |
Now that the clone methods used by `MapMetadata()` don't do any
remapping (and return a temporary), they make more sense as member
functions on `MDNode` (and subclasses).
llvm-svn: 226541
|
| |
|
|
|
|
|
|
| |
Change `HeaderBuilder` API to work well even when it's not starting with
a tag. There's already one case like this, and the tag is moving
elsewhere as part of PR22235.
llvm-svn: 226540
|
| |
|
|
|
|
| |
Extract most of `PARSE_MD_FIELD()` into a function.
llvm-svn: 226539
|
| |
|
|
| |
llvm-svn: 226538
|
| |
|
|
|
|
|
|
|
|
| |
a DominatorTree argument as that is the analysis that it wants to
update.
This removes the last non-loop utility function in Utils/ which accepts
a raw Pass argument.
llvm-svn: 226537
|
| |
|
|
|
|
|
|
|
|
| |
Fix a leak in `LLVMContextImpl` teardown that the leak sanitizer tracked
down [1]. I've just switched to automatic dispatch here (since I'll
inevitably forget again with the next class).
[1]: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/811/steps/check-llvm%20asan/logs/stdio
llvm-svn: 226536
|
| |
|
|
| |
llvm-svn: 226535
|
| |
|
|
| |
llvm-svn: 226534
|
| |
|
|
| |
llvm-svn: 226533
|
| |
|
|
| |
llvm-svn: 226532
|
| |
|
|
|
|
|
|
| |
Rather than relying on updating switch statements correctly, detect
whether `setHash()` exists in the subclass. If so, call
`recalculateHash()` and `setHash(0)` appropriately.
llvm-svn: 226531
|