- Sep 19, 2013
-
-
Andrew Trick authored
llvm-svn: 190973
-
Reed Kotler authored
1) make sure that the first two instructions of the sequence cannot separate from each other. The linker requires that they be sequential. If they get separated, it can still work but it will not work in all cases because the first of the instructions mostly involves the hi part of the pc relative offset and that part changes slowly. You would have to be at the right boundary for this to matter. 2) make sure that this sequence begins on a longword boundary. There appears to be a bug in binutils which makes some of these calculations get messed up if the instruction sequence does not begin on a longword boundary. This is being investigated with the appropriate binutils folks. llvm-svn: 190966
-
Adrian Prantl authored
Use the DIVariable::isIndirect() flag set by the frontend instead of guessing whether to set the machine location's indirection bit. Paired commit with CFE. llvm-svn: 190961
-
- Sep 18, 2013
-
-
Preston Gurd authored
-march=x86 to SLM test. llvm-svn: 190958
-
Preston Gurd authored
Atom Silvermont. Patch by Sriram Murali. llvm-svn: 190957
-
Filip Pizlo authored
advertised - but it does have the caveat that calls to DynamicLibrary::AddSymbol will "reset" if you shutdown llvm and try to come back for seconds. This is a subtle behavior change, but I'm assuming that nobody is affected by it. llvm-svn: 190946
-
Chandler Carruth authored
-Wunused-private-field with Clang. llvm-svn: 190941
-
Chandler Carruth authored
llvm-svn: 190940
-
Kostya Serebryany authored
[asan] call __asan_stack_malloc_N only if use-after-return detection is enabled with the run-time option llvm-svn: 190939
-
NAKAMURA Takumi authored
A couple of tests, in llvm/test/Transforms/*/xcore, are XCore-specific. They should be excluded when XCore is not built. llvm-svn: 190938
-
NAKAMURA Takumi authored
llvm-svn: 190937
-
Robert Lytton authored
XCore target: Add XCoreTargetTransformInfo This is where getNumberOfRegisters() resides, which in turn returns the number of vector registers (=0). llvm-svn: 190936
-
Andrea Di Biagio authored
llvm-svn: 190934
-
Richard Sandiford authored
For some reason I never got around to adding these at the same time as the signed versions. No idea why. I'm not sure whether this SystemZII::BranchC* stuff is useful, or whether it should just be replaced with an "is normal" flag. I'll leave that for later though. There are some boundary conditions that can be tweaked, such as preferring unsigned comparisons for equality with [128, 256), and "<= 255" over "< 256", but again I'll leave those for a separate patch. llvm-svn: 190930
-
Joey Gouly authored
llvm-svn: 190929
-
Joey Gouly authored
Patch by Bradley Smith! llvm-svn: 190928
-
Filip Pizlo authored
I'll roll it back in when I have a chance to look at it in detail. llvm-svn: 190923
-
Filip Pizlo authored
advertised - but it does have the caveat that calls to DynamicLibrary::AddSymbol will "reset" if you shutdown llvm and try to come back for seconds. This is a subtle behavior change, but I'm assuming that nobody is affected by it. llvm-svn: 190921
-
Craig Topper authored
Prevent extra calls to ToggleFeature for Feature64Bit and FeatureCMOV if they've already been enabled. The extra call ends up clearing the bit in FeatureBits since its a 'toggle'. Can't prove that anything was broken because of this since I don't think the FeatureBits for these are used. llvm-svn: 190920
-
Craig Topper authored
Fix X86 subtarget to not overwrite the autodetected features by calling InitMCProcessorInfo right after detecting them. Instead add a new function that only updates the scheduling model and call that. llvm-svn: 190919
-
Craig Topper authored
llvm-svn: 190917
-
Craig Topper authored
llvm-svn: 190916
-
David Blaikie authored
llvm-svn: 190905
-
Matt Arsenault authored
If address space 0 was smaller than the address space in a constant inttoptr/ptrtoint pair, the wrong mask size would be used. llvm-svn: 190899
-
Reid Kleckner authored
Summary: We indicate that the object files are safe by emitting a @feat.00 absolute address symbol. The address is presumably interpreted as a bitfield of features that the compiler would like to enable. Bit 0 is documented in the PE COFF spec to opt in to "registered SEH", which is what /safeseh enables. LLVM's object files are safe by default because LLVM doesn't know how to produce SEH handlers. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1691 llvm-svn: 190898
-
Matt Arsenault authored
llvm-svn: 190897
-
Matt Arsenault authored
For now it happens the argument is always the same. llvm-svn: 190896
-
Matt Arsenault authored
llvm-svn: 190893
-
Quentin Colombet authored
To avoid regressions with bitfield optimizations, this slicing should take place later, like ISel time. llvm-svn: 190891
-
- Sep 17, 2013
-
-
Reid Kleckner authored
In particular, this means we emit non-external symbols defined to variables, such as aliases or absolute addresses. This is needed to implement /safeseh, and it appears there was some confusion about what symbols to emit previously. llvm-svn: 190888
-
Reid Kleckner authored
llvm-svn: 190887
-
Eric Christopher authored
llvm-svn: 190886
-
Matt Arsenault authored
Some of this code is no longer necessary since int<->ptr casts are no longer occur as of r187444. This also fixes handling vectors of pointers, and adds a bunch of new testcases for vectors and address spaces. llvm-svn: 190885
-
Bill Schmidt authored
Documenting a design choice to generate only medium model sequences for TLS addresses at this time. Small and large code models could be supported if necessary. llvm-svn: 190883
-
Bill Schmidt authored
Large code model on PPC64 requires creating and referencing TOC entries when using the addis/ld form of addressing. This was not being done in all cases. The changes in this patch to PPCAsmPrinter::EmitInstruction() fix this. Two test cases are also modified to reflect this requirement. Fast-isel was not creating correct code for loading floating-point constants using large code model. This also requires the addis/ld form of addressing. Previously we were using the addis/lfd shortcut which is only applicable to medium code model. One test case is modified to reflect this requirement. llvm-svn: 190882
-
Arnold Schwaighofer authored
Upcoming SLP vectorization improvements will want to be able to estimate costs of horizontal reductions. Add infrastructure to support this. We model reductions as a series of (shufflevector,add) tuples ultimately followed by an extractelement. For example, for an add-reduction of <4 x float> we could generate the following sequence: (v0, v1, v2, v3) \ \ / / \ \ / + + (v0+v2, v1+v3, undef, undef) \ / ((v0+v2) + (v1+v3), undef, undef) %rdx.shuf = shufflevector <4 x float> %rdx, <4 x float> undef, <4 x i32> <i32 2, i32 3, i32 undef, i32 undef> %bin.rdx = fadd <4 x float> %rdx, %rdx.shuf %rdx.shuf7 = shufflevector <4 x float> %bin.rdx, <4 x float> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef> %bin.rdx8 = fadd <4 x float> %bin.rdx, %rdx.shuf7 %r = extractelement <4 x float> %bin.rdx8, i32 0 This commit adds a cost model interface "getReductionCost(Opcode, Ty, Pairwise)" that will allow clients to ask for the cost of such a reduction (as backends might generate more efficient code than the cost of the individual instructions summed up). This interface is excercised by the CostModel analysis pass which looks for reduction patterns like the one above - starting at extractelements - and if it sees a matching sequence will call the cost model interface. We will also support a second form of pairwise reduction that is well supported on common architectures (haddps, vpadd, faddp). (v0, v1, v2, v3) \ / \ / (v0+v1, v2+v3, undef, undef) \ / ((v0+v1)+(v2+v3), undef, undef, undef) %rdx.shuf.0.0 = shufflevector <4 x float> %rdx, <4 x float> undef, <4 x i32> <i32 0, i32 2 , i32 undef, i32 undef> %rdx.shuf.0.1 = shufflevector <4 x float> %rdx, <4 x float> undef, <4 x i32> <i32 1, i32 3, i32 undef, i32 undef> %bin.rdx.0 = fadd <4 x float> %rdx.shuf.0.0, %rdx.shuf.0.1 %rdx.shuf.1.0 = shufflevector <4 x float> %bin.rdx.0, <4 x float> undef, <4 x i32> <i32 0, i32 undef, i32 undef, i32 undef> %rdx.shuf.1.1 = shufflevector <4 x float> %bin.rdx.0, <4 x float> undef, <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef> %bin.rdx.1 = fadd <4 x float> %rdx.shuf.1.0, %rdx.shuf.1.1 %r = extractelement <4 x float> %bin.rdx.1, i32 0 llvm-svn: 190876
-
Arnold Schwaighofer authored
We can't insert an insertelement after an invoke. We would have to split a critical edge. So when we see a phi node that uses an invoke we just give up. radar://14990770 llvm-svn: 190871
-
Quentin Colombet authored
other in memory. The motivation was to get rid of truncate and shift right instructions that get in the way of paired load or floating point load. E.g., Consider the following example: struct Complex { float real; float imm; }; When accessing a complex, llvm was generating a 64-bits load and the imm field was obtained by a trunc(lshr) sequence, resulting in poor code generation, at least for x86. The idea is to declare that two load instructions is the canonical form for loading two arithmetic type, which are next to each other in memory. Two scalar loads at a constant offset from each other are pretty easy to detect for the sorts of passes that like to mess with loads. <rdar://problem/14477220> llvm-svn: 190870
-
Preston Gurd authored
llvm-svn: 190869
-
Serge Pavlov authored
llvm-svn: 190866
-