- Jan 16, 2013
-
-
Daniel Dunbar authored
llvm-svn: 172659
-
Renato Golin authored
Moving the X86CostTable to a common place, so that other back-ends can share the code. Also simplifying it a bit and commoning up tables with one and two types on operations. llvm-svn: 172658
-
-
Michael J. Spencer authored
llvm-svn: 172655
-
Eric Christopher authored
llvm-svn: 172652
-
Eric Christopher authored
llvm-svn: 172651
-
Eric Christopher authored
llvm-svn: 172646
-
Michael J. Spencer authored
Patch by Jakub Staszak. llvm-svn: 172645
-
Michael J. Spencer authored
llvm-svn: 172644
-
Eli Bendersky authored
llvm-svn: 172642
-
Eli Bendersky authored
llvm-svn: 172640
-
Eli Bendersky authored
llvm-svn: 172638
-
Eli Bendersky authored
return into the safe harbor of AsmParser's private areas. llvm-svn: 172637
-
Daniel Dunbar authored
- Instead of computing a bunch of buckets of different flag types, just do an incremental link resolving conflicts as they arise. - This also has the advantage of making the link result deterministic and not dependent on map iteration order. llvm-svn: 172634
-
Kevin Enderby authored
AT_producer. Which includes clang's version information so we can tell which version of the compiler was used. This is the first of two steps to allow us to do that. This is the llvm-mc change to provide a method to set the AT_producer string. The second step, coming soon to a clang near you, will have the clang driver pass the value of getClangFullVersion() via an flag when invoking the integrated assembler on assembly source files. rdar://12955296 llvm-svn: 172630
-
Peter Collingbourne authored
In r143502, we renamed getHostTriple() to getDefaultTargetTriple() as part of work to allow the user to supply a different default target triple at configure time. This change also affected the JIT. However, it is inappropriate to use the default target triple in the JIT in most circumstances because this will not necessarily match the current architecture used by the process, leading to illegal instruction and other such errors at run time. Introduce the getProcessTriple() function for use in the JIT and its clients, and cause the JIT to use it. On architectures with a single bitness, the host and process triples are identical. On other architectures, the host triple represents the architecture of the host CPU, while the process triple represents the architecture used by the host CPU to interpret machine code within the current process. For example, when executing 32-bit code on a 64-bit Linux machine, the host triple may be 'x86_64-unknown-linux-gnu', while the process triple may be 'i386-unknown-linux-gnu'. This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple platforms. Differential Revision: http://llvm-reviews.chandlerc.com/D254 llvm-svn: 172627
-
Eli Bendersky authored
llvm-svn: 172622
-
Evgeniy Stepanov authored
llvm-svn: 172615
-
Evgeniy Stepanov authored
llvm-svn: 172614
-
Benjamin Kramer authored
llvm-svn: 172612
-
Benjamin Kramer authored
Should fix the arm buildbot (which only builds the arm target). llvm-svn: 172611
-
Alexey Samsonov authored
ASan: wrap mapping scale and offset in a struct and make it a member of ASan passes. Add test for non-default mapping scale and offset. No functionality change llvm-svn: 172610
-
Benjamin Kramer authored
Without a triple opt falls back to NoTTI which comes closer to LSR's pre-TTI behavior. llvm-svn: 172609
-
Michael Gottesman authored
[ObjCARC] Turn off ignoring unwind edges in ObjCARC when -fno-objc-arc-exception is enabled due to it's affect on correctness. Specifically according to the semantics of ARC -fno-objc-arc-exception simply states that it is expected that the unwind path out of a call *MAY* not release objects. Thus we can have the situation where a release gets moved into a catch block which we ignore when we remove a retain/release pair resulting in (even though we assume the program is exiting anyways) the cleanup code path potentially blowing up before program exit. llvm-svn: 172599
-
Jack Carter authored
llvm-svn: 172594
-
Eric Christopher authored
of a class. Emit static data member declarations and definitions through correctly. Part of PR14471. Patch by Paul Robinson! llvm-svn: 172590
-
Eli Bendersky authored
Since we already have this type it's a shame to keep dragging a pair of object and method around explicitly. llvm-svn: 172584
-
David Greene authored
Use --enable-werror during configure time rather than --with-extra-options. This is cleaner and easier to read. llvm-svn: 172581
-
Dmitri Gribenko authored
llvm-svn: 172580
-
Jack Carter authored
Hope you are feeling better. The Mips RDHWR (Read Hardware Register) instruction was not tested for assembler or dissassembler consumption. This patch adds that functionality. Contributer: Vladimir Medic llvm-svn: 172579
-
Eric Christopher authored
using the DW_FORM_GNU_addr_index and a separate .debug_addr section which stays in the executable and is fully linked. Sneak in two other small changes: a) Print out the debug_str_offsets.dwo section. b) Change form we're expecting the entries in the debug_str_offsets.dwo section to take from ULEB128 to U32. Add tests for all of this in the fission-cu.ll test. llvm-svn: 172578
-
David Greene authored
Avoid a compiler warning about comparing disjoint enums but casting them to int first. llvm-svn: 172577
-
Nadav Rotem authored
llvm-svn: 172576
-
Eli Bendersky authored
into which we can emit single instructions without fixups (which is most instructions). This is an optimization required because MCDataFragment is prety large (240 bytes on x64), with no change in functionality. For large programs, this reduces memory usage overhead required for bundling by 40%. To make the code as palatable as possible, the MCEncodedFragment interface was further fragmented (no pun intended) and MCEncodedFragmentWithFixups is used as the interface to work against when the user expects fixups. MCDataFragment and MCRelaxableFragment implement this interface, while the new MCCompactEncodedInstFragment implements MCEncodeFragment. llvm-svn: 172572
-
Chad Rosier authored
// FIXME: Constraints are hard coded to 'm', but we need an 'r' // constraint for addressof. This needs to be cleaned up! Test cases are already in place. Specifically, clang/test/CodeGen/ms-inline-asm.c t15(), t16(), and t24(). llvm-svn: 172569
-
- Jan 15, 2013
-
-
Eli Bendersky authored
After discussing the refactoring with Jim and Daniel, the following changes were made: * All generic directive parsing is now done by AsmParser itself. The previous division between it and GenericAsmParser did not have clear boundaries and just produced unnatural code of GenericAsmParser juggling the internals of AsmParser through an interface. The division of responsibilities is now clear: target-specific directives, other extensions (used by platform-specific parseres), and generic directives. * Priority for directive parsing was reshuffled to ask extensions first and check the generic directives later. No change in functionality. llvm-svn: 172568
-
Michael J. Spencer authored
llvm-svn: 172556
-
Shuxin Yang authored
some optimization opportunities (in the enclosing supper-expressions). rule 1. (-0.0 - X ) * Y => -0.0 - (X * Y) if expression "-0.0 - X" has only one reference. rule 2. (0.0 - X ) * Y => -0.0 - (X * Y) if expression "0.0 - X" has only one reference, and the instruction is marked "noSignedZero". 2. Eliminate negation (The compiler was already able to handle these opt if the 0.0s are replaced with -0.0.) rule 3: (0.0 - X) * (0.0 - Y) => X * Y rule 4: (0.0 - X) * C => X * -C if the expr is flagged "noSignedZero". 3. Rule 5: (X*Y) * X => (X*X) * Y if X!=Y and the expression is flagged with "UnsafeAlgebra". The purpose of this transformation is two-fold: a) to form a power expression (of X). b) potentially shorten the critical path: After transformation, the latency of the instruction Y is amortized by the expression of X*X, and therefore Y is in a "less critical" position compared to what it was before the transformation. 4. Remove the InstCombine code about simplifiying "X * select". The reasons are following: a) The "select" is somewhat architecture-dependent, therefore the higher level optimizers are not able to precisely predict if the simplification really yields any performance improvement or not. b) The "select" operator is bit complicate, and tends to obscure optimization opportunities. It is btter to keep it as low as possible in expr tree, and let CodeGen to tackle the optimization. llvm-svn: 172551
-
Daniel Dunbar authored
llvm-svn: 172550
-
Daniel Dunbar authored
llvm-svn: 172549
-