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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162420 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162417 91177308-0d34-0410-b5e6-96231b3b80d8
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),
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162409 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162404 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162381 91177308-0d34-0410-b5e6-96231b3b80d8
optimizations are guarded by the -enable-double-float-shrink LLVM option.
Last bit of PR13574. Patch by Weiming Zhao <weimingz@codeaurora.org>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162368 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162367 91177308-0d34-0410-b5e6-96231b3b80d8
to prevent it from being clobbered. mips uses $gp to access small data section.
This bug was originally reported by Carl Norum.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162340 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162337 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162334 91177308-0d34-0410-b5e6-96231b3b80d8
SelectionDAG's 'init' has not been called when the SelectionDAGBuilder is
constructed (in SelectionDAGISel's constructor), so this was previously always
initialized with 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162333 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162312 91177308-0d34-0410-b5e6-96231b3b80d8
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)?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162301 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162295 91177308-0d34-0410-b5e6-96231b3b80d8
consistent with the other "expected identifier" errors.
Extracted from the Andy/PaX patch. I added the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162291 91177308-0d34-0410-b5e6-96231b3b80d8
The MCJIT doesn't need or want a TargetJITInfo. That's vestigal from the old
JIT, so just remove it.
rdar://12119347
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162280 91177308-0d34-0410-b5e6-96231b3b80d8
number of bits was bigger than 32. I checked every use of this function
that I could find and it looks like the maximum number of bits is 32, so I've
added an assertion checking this property, and a type cast to (hopefully) stop
PVS-Studio from warning about this in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162277 91177308-0d34-0410-b5e6-96231b3b80d8
This optimization is really just replacing allocas wholesale with
globals, there is no scalarization.
The underlying motivation for this patch is to simplify the SROA pass
and focus it on splitting and promoting allocas.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162271 91177308-0d34-0410-b5e6-96231b3b80d8
