- Apr 03, 2013
-
-
Hal Finkel authored
I discussed this with Bill Schmidt on IRC, and it was decided that this is a safe and reasonable default. llvm-svn: 178659
-
Hal Finkel authored
llvm-svn: 178658
-
Hal Finkel authored
llvm-svn: 178657
-
Ulrich Weigand authored
More direct types in PowerPC AltiVec intrinsics. This patch follows up on work done by Bill Schmidt in r178277, and replaces most of the remaining uses of VRRC in ISEL DAG patterns. The resulting .inc files are identical except for comments, so no change in code generation is expected. llvm-svn: 178656
-
Bill Schmidt authored
For this we need to use a libcall. Previously LLVM didn't implement libcall support for frem, so I've added it in the usual straightforward manner. A test case from the bug report is included. llvm-svn: 178639
-
Tim Northover authored
llvm-svn: 178637
-
Aaron Ballman authored
when getting the host processor information. It emits a .byte sequence on GNUC compilers to work around lack of xgetbv support with older assemblers, and resolves a comment typo found in the previous patch. llvm-svn: 178636
-
Timur Iskhodzhanov authored
llvm-svn: 178634
-
Tim Northover authored
It's a bit of churn in the blame log, but I think there are real benefits to the newer system so I'm making the change in one go. llvm-svn: 178633
-
Eric Christopher authored
llvm-svn: 178624
-
Eric Christopher authored
llvm-svn: 178623
-
Jakob Stoklund Olesen authored
The same compare instruction is used for 32-bit and 64-bit compares. It sets two different sets of flags: icc and xcc. This patch adds a conditional branch instruction using the xcc flags for 64-bit compares. llvm-svn: 178621
-
Hal Finkel authored
These refer to the reciprocal estimate support recently committed. llvm-svn: 178618
-
Hal Finkel authored
When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
-
Rafael Espindola authored
This finally fixes the encoding. The patch also * Removes eh-frame.ll. It was an unnecessary .ll to .o test that was checking the wrong value. * Merge fde-reloc.s and eh-frame.s into a single test, since the only difference was the run lines. * Don't blindly test the content of the entire .eh_frame section. It makes it hard to anyone actually fixing a bug and hitting a difference in a binary blob. Instead, use a CHECK for each field and document what is being checked. llvm-svn: 178615
-
Aaron Ballman authored
Rolling back the AVX support patch due to breaking a gcc 4.6 build bot that doesn't understand the xgetbv instruction for some reason. Will revisit when time permits. llvm-svn: 178614
-
Michael Gottesman authored
Remove an optimization where we were changing an objc_autorelease into an objc_autoreleaseReturnValue. The semantics of ARC implies that a pointer passed into an objc_autorelease must live until some point (potentially down the stack) where an autorelease pool is popped. On the other hand, an objc_autoreleaseReturnValue just signifies that the object must live until the end of the given function at least. Thus objc_autorelease is stronger than objc_autoreleaseReturnValue in terms of the semantics of ARC* implying that performing the given strength reduction without any knowledge of how this relates to the autorelease pool pop that is further up the stack violates the semantics of ARC. *Even though objc_autoreleaseReturnValue if you know that no RV optimization will occur is more computationally expensive. llvm-svn: 178612
-
Michael Gottesman authored
llvm-svn: 178605
-
Aaron Ballman authored
llvm-svn: 178604
-
Aaron Ballman authored
when getting the host processor information. llvm-svn: 178598
-
Eric Christopher authored
llvm-svn: 178589
-
Akira Hatanaka authored
This patch initializes t9 to the handler address, but only if the relocation model is pic. This handles the case where handler to which eh.return jumps points to the start of the function. Patch by Sasa Stankovic. llvm-svn: 178588
-
Eric Christopher authored
llvm-svn: 178586
-
Eric Christopher authored
llvm-svn: 178585
-
Akira Hatanaka authored
This patch fixes the following two tests which have been failing on llvm-mips-linux builder since r178403: LLVM :: Analysis/Profiling/load-branch-weights-ifs.ll LLVM :: Analysis/Profiling/load-branch-weights-loops.ll llvm-svn: 178584
-
Jakob Stoklund Olesen authored
It it still possible to extract information from itineraries, for example. llvm-svn: 178582
-
- Apr 02, 2013
-
-
Chad Rosier authored
qualifiers. This patch only adds support for parsing these identifiers in the X86AsmParser. The front-end interface isn't capable of looking up these identifiers at this point in time. The end result is the compiler now errors during object file emission, rather than at parse time. Test case coming shortly. Part of rdar://13499009 and PR13340 llvm-svn: 178566
-
Bill Schmidt authored
When doing a partword atomic operation, a lwarx was being paired with a stdcx. instead of a stwcx. when compiling for a 64-bit target. The target has nothing to do with it in this case; we always need a stwcx. Thanks to Kai Nacke for reporting the problem. llvm-svn: 178559
-
Jakob Stoklund Olesen authored
This should fix the PPC buildbots. llvm-svn: 178558
-
Jakob Stoklund Olesen authored
The new instruction scheduling models provide information about the number of cycles consumed on each processor resource. This makes it possible to estimate ILP more accurately than simply counting instructions / issue width. The functions getResourceDepth() and getResourceLength() now identify the limiting processor resource, and return a cycle count based on that. This gives more precise resource information, particularly in traces that use one resource a lot more than others. llvm-svn: 178553
-
Chad Rosier authored
llvm-svn: 178549
-
Arnold Schwaighofer authored
This is helps on architectures where i8,i16 are not legal but we have byte, and short loads/stores. Allowing us to merge copies like the one below on ARM. copy(char *a, char *b, int n) { do { int t0 = a[0]; int t1 = a[1]; b[0] = t0; b[1] = t1; radar://13536387 llvm-svn: 178546
-
Justin Holewinski authored
llvm-svn: 178536
-
Bill Wendling authored
The iterator could be invalidated when it's recursively deleting a whole bunch of constant expressions in a constant initializer. Note: This was only reproducible if `opt' was run on a `.bc' file. If `opt' was run on a `.ll' file, it wouldn't crash. This is why the test first pushes the `.ll' file through `llvm-as' before feeding it to `opt'. PR15440 llvm-svn: 178531
-
Jakob Stoklund Olesen authored
There is only a few new instructions, the rest is handled with patterns. llvm-svn: 178528
-
Jakob Stoklund Olesen authored
SPARC v9 extends all ALU instructions to 64 bits, so we simply need to add patterns to use them for both i32 and i64 values. llvm-svn: 178527
-
Jakob Stoklund Olesen authored
The last resort pattern produces 6 instructions, and there are still opportunities for materializing some immediates in fewer instructions. llvm-svn: 178526
-
Jakob Stoklund Olesen authored
SPARC v9 defines new 64-bit shift instructions. The 32-bit shift right instructions are still usable as zero and sign extensions. This adds new F3_Sr and F3_Si instruction formats that probably should be used for the 32-bit shifts as well. They don't really encode an simm13 field. llvm-svn: 178525
-
Jakob Stoklund Olesen authored
The 'sparc' architecture produces 32-bit code while 'sparcv9' produces 64-bit code. It is also possible to run 32-bit code using SPARC v9 instructions with: llc -march=sparc -mattr=+v9 llvm-svn: 178524
-
Jakob Stoklund Olesen authored
This is far from complete, but it is enough to make it possible to write test cases using i64 arguments. Missing features: - Floating point arguments. - Receiving arguments on the stack. - Calls. llvm-svn: 178523
-