The logic for recomputing latency based on a ScheduleDAG edge was
shady. This bypasses the problem by requiring the client to provide
operand indices. This ensures consistent use of the machine model's
API.
llvm-svn: 162420
the temporary register that was used to load the immediate. Currently, it always
returns register $at, but this will change if, in the future, we decide to use
another register.
No changes in functionality.
llvm-svn: 162417
When reporting an error for a defm, we would previously only report the
location of the outer defm, which is not always where the error is.
Now we also print the location of the expanded multiclass defs:
lib/Target/X86/X86InstrSSE.td:2902:12: error: foo
defm ADD : basic_sse12_fp_binop_s<0x58, "add", fadd, SSE_ALU_ITINS_S>,
^
lib/Target/X86/X86InstrSSE.td:2801:11: note: instantiated from multiclass
defm PD : sse12_fp_packed<opc, !strconcat(OpcodeStr, "pd"), OpNode, VR128,
^
lib/Target/X86/X86InstrSSE.td:194:5: note: instantiated from multiclass
def rm : PI<opc, MRMSrcMem, (outs RC:$dst), (ins RC:$src1, x86memop:$src2),
^
llvm-svn: 162409
The MCInst is immediately passed to the copy-constructor for local
storage, so there's no need for the parameter itself to be by-value.
llvm-svn: 162404
Assertion failed: (Start.isValid() == End.isValid() && "Start and end should
either both be valid or both be invalid!")
when parsing inline asm. SMLoc assumes that the first char * in the source is
invalid. However, when parsing an inline asm the mnemonic is at this location.
I don't want to change SMLoc, so use a trivial workaround.
llvm-svn: 162381
optimizations are guarded by the -enable-double-float-shrink LLVM option.
Last bit of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>.
llvm-svn: 162368
Based on CR feedback from r162301 and Craig Topper's refactoring in r162347
here are a few other places that could use the same API (& in one instance drop
a Function.h dependency).
llvm-svn: 162367
No change in interface or functionality. Purely under-the-hood
details of the generated function that change.
The X86 assembly parser is reduced in size by over 15% and ARM by
over 10%.
No performance change by my measurements.
llvm-svn: 162337
within the codegen EK_GPRel64BlockAddress. This was not
supported for direct object output and resulted in an assertion.
This change adds support for EK_GPRel64BlockAddress for
direct object.
One fallout from this is to turn on rela relocations
for mips64 to match gas.
llvm-svn: 162334
SelectionDAG's 'init' has not been called when the SelectionDAGBuilder is
constructed (in SelectionDAGISel's constructor), so this was previously always
initialized with 0.
llvm-svn: 162333
int64_t, Symbol64TableEntry is actually only stored with 4-byte alignment
within the file.
The usage of #pragma pack here is copied from the corresponding code in
Support/Endian.h, so shouldn't introduce any new portability problems.
llvm-svn: 162312
According to http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
it's suggested that compile_commands.json in the root of the LLVM source tree
should be a symlink to the json file produced by your build system of choice.
So here's a patch so it doesn't turn up in git status, etc.
llvm-svn: 162305
Even looking at the revision history I couldn't quite piece together why this
cast was ever written in the first place, but I assume it was because of some
change in the inheritance, perhaps this function was reimplemented in a
derived type & this caller was meant to get the base version (& it wasn't
virtual)?
llvm-svn: 162301
this is the index of the operand that failed to match.
Note: This may cause a buildbot failure due to an API mismatch in clang. Should
recover with my next commit to clang.
llvm-svn: 162295
Eric Christopher