| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 146182
|
| |
|
|
|
|
|
|
| |
don't seem to be patterns for these, so I don't know why they were marked legal in the first place.
Fixes failures caused by r146171.
llvm-svn: 146180
|
| |
|
|
| |
llvm-svn: 146179
|
| |
|
|
| |
llvm-svn: 146177
|
| |
|
|
|
|
|
|
|
|
| |
- Modify lowering of global TLS address nodes.
- Modify isel of ThreadPointer.
- Wrap target global TLS address nodes that are operands of loads with WrapperPIC.
- Remove Mips-specific DAG nodes TlsGd, TprelHi and TprelLo, which can be
substituted with other existing nodes.
llvm-svn: 146175
|
| |
|
|
|
|
| |
SDNodes. Mark these nodes as illegal by default, unless the target declares otherwise.
llvm-svn: 146171
|
| |
|
|
|
|
| |
rdar://10550084
llvm-svn: 146170
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
led to the following code in X86Subtarget.cpp
if (HasAVX)
X86SSELevel = NoMMXSSE;
This is so patterns that are predicated on hasSSE3, etc. would not be selected when avx is available. Instead, the AVX variant is selected.
However, this breaks instructions which do not have AVX variants.
The right way to fix this is for the SSE but not-AVX patterns to predicate on something like hasSSE3() && !hasAVX().
Then we can take out the hack in X86Subtarget.cpp. Patterns which do not have AVX variants do not need to change.
However, we need to audit all the patterns before we make the change. This patch is workaround that fixes one specific case,
the prefetch instructions. rdar://10538297
llvm-svn: 146163
|
| |
|
|
|
|
|
| |
sqrt/exp (fix for FSQRT, FSIN, FCOS, FPOWI, FPOW, FLOG, FLOG2, FLOG10, FEXP,
FEXP2).", it is failing tests.
llvm-svn: 146157
|
| |
|
|
|
|
| |
and fix the encoding.
llvm-svn: 146151
|
| |
|
|
|
|
| |
for FSQRT, FSIN, FCOS, FPOWI, FPOW, FLOG, FLOG2, FLOG10, FEXP, FEXP2).
llvm-svn: 146143
|
| |
|
|
|
|
| |
(another find by -verify-machineinstrs)
llvm-svn: 146137
|
| |
|
|
| |
llvm-svn: 146125
|
| |
|
|
|
|
|
|
|
|
| |
It is not used any more. We are tracking inline assembly misalignments
directly through the BBInfo.Unalign and KnownBits fields.
A simple conservative size estimate is not good enough since it can
cause alignment padding to be underestimated.
llvm-svn: 146124
|
| |
|
|
| |
llvm-svn: 146123
|
| |
|
|
| |
llvm-svn: 146121
|
| |
|
|
| |
llvm-svn: 146120
|
| |
|
|
| |
llvm-svn: 146119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compute alignment padding before and after basic blocks dynamically.
Heed basic block alignment.
This simplifies bookkeeping because we don't have to constantly add and
remove padding from BBInfo.Size. It also makes it possible to track the
extra known alignment bits we get after a tBR_JTr terminator and when
entering an aligned basic block.
This makes the ARMConstantIslandPass aware of aligned basic blocks.
It is tricky to model block alignment correctly when dealing with inline
assembly and tBR_JTr instructions that have variable size. If inline
assembly turns out to be smaller than expected, that may cause following
alignment padding to be larger than expected. This could cause constant
pool entries to move out of range.
To avoid that problem, we use the worst case alignment padding following
inline assembly. This may cause slightly suboptimal constant island
placement in aligned basic blocks following inline assembly. Normal
functions should be unaffected.
llvm-svn: 146118
|
| |
|
|
| |
llvm-svn: 146116
|
| |
|
|
| |
llvm-svn: 146115
|
| |
|
|
| |
llvm-svn: 146114
|
| |
|
|
| |
llvm-svn: 146111
|
| |
|
|
|
|
| |
For 'gas' compatibility.
llvm-svn: 146106
|
| |
|
|
|
|
| |
RDHWR.
llvm-svn: 146101
|
| |
|
|
| |
llvm-svn: 146100
|
| |
|
|
| |
llvm-svn: 146099
|
| |
|
|
| |
llvm-svn: 146097
|
| |
|
|
| |
llvm-svn: 146096
|
| |
|
|
| |
llvm-svn: 146095
|
| |
|
|
| |
llvm-svn: 146093
|
| |
|
|
| |
llvm-svn: 146091
|
| |
|
|
|
|
|
| |
been normalized and more descriptive comments added. Patch by Reed
Kotler and Jack Carter.
llvm-svn: 146088
|
| |
|
|
| |
llvm-svn: 146086
|
| |
|
|
| |
llvm-svn: 146081
|
| |
|
|
| |
llvm-svn: 146080
|
| |
|
|
| |
llvm-svn: 146063
|
| |
|
|
| |
llvm-svn: 146062
|
| |
|
|
| |
llvm-svn: 146059
|
| |
|
|
| |
llvm-svn: 146057
|
| |
|
|
|
|
|
|
| |
When the file isn't being built with subsections-via-symbols, symbol
differences involving non-local symbols can be resolved more aggressively.
Needed for gas compatibility.
llvm-svn: 146054
|
| |
|
|
|
|
| |
rdar://10542474
llvm-svn: 146046
|
| |
|
|
| |
llvm-svn: 146042
|
| |
|
|
| |
llvm-svn: 146039
|
| |
|
|
|
|
| |
not using integer loads other than v2i64/v4i64 since the others are all promoted.
llvm-svn: 146031
|
| |
|
|
| |
llvm-svn: 146030
|
| |
|
|
| |
llvm-svn: 146029
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.
For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.
llvm-svn: 146026
|
| |
|
|
|
|
| |
other problems found with -verify-machineinstrs
llvm-svn: 146024
|
| |
|
|
| |
llvm-svn: 146023
|