|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| | llvm-svn: 147966 | 
| | 
| 
| 
| 
| 
| 
| 
| | This uses TLS slot 90, which actually belongs to JavaScriptCore. We only support
frames with static size
Patch by Brian Anderson.
llvm-svn: 147960 | 
| | 
| 
| 
| 
| 
| | Patch by Brian Anderson.
llvm-svn: 147958 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | hoped this would revive one of the llvm-gcc selfhost build bots, but it
didn't so it doesn't appear that my transform is the culprit.
If anyone else is seeing failures, please let me know!
llvm-svn: 147957 | 
| | 
| 
| 
| 
| 
| 
| 
| | This is a comparison of two addresses, and GCC does the comparison unsigned.
Patch by Brian Anderson.
llvm-svn: 147954 | 
| | 
| 
| 
| 
| 
| | Patch by Brian Anderson.
llvm-svn: 147952 | 
| | 
| 
| 
| | llvm-svn: 147949 | 
| | 
| 
| 
| 
| 
| | zero untouched elements. Use INSERT_VECTOR_ELT instead.
llvm-svn: 147948 | 
| | 
| 
| 
| 
| 
| 
| 
| | strange build bot failures that look like a miscompile into an infloop.
I'll investigate this tomorrow, but I'd both like to know whether my
patch is the culprit, and get the bots back to green.
llvm-svn: 147945 | 
| | 
| 
| 
| 
| 
| | lots of lines of code. No functionality changed.
llvm-svn: 147942 | 
| | 
| 
| 
| 
| 
| | SRL-rooted code.
llvm-svn: 147941 | 
| | 
| 
| 
| 
| 
| 
| | factor the differences that were hiding in one of them into its other
caller, the SRL handling code. No change in behavior.
llvm-svn: 147940 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | mask+shift pairs at the beginning of the ISD::AND case block, and then
hoist the final pattern into a helper function, simplifying and
reflowing it appropriately. This should have no observable behavior
change, but several simplifications fell out of this such as directly
computing the new mask constant, etc.
llvm-svn: 147939 | 
| | 
| 
| 
| 
| 
| 
| | I don't think the compact encoding code is right, but at least is has
defined behavior now.
llvm-svn: 147938 | 
| | 
| 
| 
| 
| 
| 
| 
| | extracts and scaled addressing modes into its own helper function. No
functionality changed here, just hoisting and layout fixes falling out
of that hoisting.
llvm-svn: 147937 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | detect a pattern which can be implemented with a small 'shl' embedded in
the addressing mode scale. This happens in real code as follows:
  unsigned x = my_accelerator_table[input >> 11];
Here we have some lookup table that we look into using the high bits of
'input'. Each entity in the table is 4-bytes, which means this
implicitly gets turned into (once lowered out of a GEP):
  *(unsigned*)((char*)my_accelerator_table + ((input >> 11) << 2));
The shift right followed by a shift left is canonicalized to a smaller
shift right and masking off the low bits. That hides the shift right
which x86 has an addressing mode designed to support. We now detect
masks of this form, and produce the longer shift right followed by the
proper addressing mode. In addition to saving a (rather large)
instruction, this also reduces stalls in Intel chips on benchmarks I've
measured.
In order for all of this to work, one part of the DAG needs to be
canonicalized *still further* than it currently is. This involves
removing pointless 'trunc' nodes between a zextload and a zext. Without
that, we end up generating spurious masks and hiding the pattern.
llvm-svn: 147936 | 
| | 
| 
| 
| | llvm-svn: 147924 | 
| | 
| 
| 
| | llvm-svn: 147923 | 
| | 
| 
| 
| 
| 
| 
| 
| | Allow LDRD to be formed from pairs with different LDR encodings. This was the original intention of the pass. Somewhere along the way, the LDR opcodes were refined which broke the optimization. We really don't care what the original opcodes are as long as they both map to the same LDRD and the immediate still fits.
Fixes rdar://10435045 ARMLoadStoreOptimization cannot handle mixed LDRi8/LDRi12
llvm-svn: 147922 | 
| | 
| 
| 
| | llvm-svn: 147890 | 
| | 
| 
| 
| 
| 
| 
| | Add a test that checks the stack alignment of a simple function for
Darwin, Linux and NetBSD for 32bit and 64bit mode.
llvm-svn: 147888 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This function runs after all constant islands have been placed, and may
shrink some instructions to their 2-byte forms.  This can actually cause
some constant pool entries to move out of range because of growing
alignment padding.
Treat instructions that may be shrunk the same as inline asm - they
erode the known alignment bits.
Also reinstate an old assertion in verify(). It is correct now that
basic block offsets include alignments.
Add a single large test case that will hopefully exercise many parts of
the constant island pass.
<rdar://problem/10670199>
llvm-svn: 147885 | 
| | 
| 
| 
| 
| 
| 
| | failing test cases on our internal AVX nightly tester.
rdar://10663637
llvm-svn: 147881 | 
| | 
| 
| 
| 
| 
| | rdar://10663487
llvm-svn: 147876 | 
| | 
| 
| 
| | llvm-svn: 147874 | 
| | 
| 
| 
| | llvm-svn: 147870 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | As the comment around 7746 says, it's better to use the x87 extended precision
here than SSE. And the generic code doesn't know how to do that. It also regains
the speed lost for the uint64_to_float.c testcase.
<rdar://problem/10669858>
llvm-svn: 147869 | 
| | 
| 
| 
| | llvm-svn: 147867 | 
| | 
| 
| 
| 
| 
| 
| 
| | of several newly un-defaulted switches. This also helps optimizers
(including LLVM's) recognize that every case is covered, and we should
assume as much.
llvm-svn: 147861 | 
| | 
| 
| 
| 
| 
| | Right now, this just adds additional entries in match table. The parser does not use them yet.
llvm-svn: 147859 | 
| | 
| 
| 
| | llvm-svn: 147855 | 
| | 
| 
| 
| | llvm-svn: 147846 | 
| | 
| 
| 
| 
| 
| | There is no vbroadcastsd xmm, but we do need to support 64-bit integers broadcasted into xmm. Also factor the AVX check into the isVectorBroadcast function. This makes more sense since the AVX2 check was already inside.
llvm-svn: 147844 | 
| | 
| 
| 
| 
| 
| | the final piece to remove the AVX hack that disabled SSE.
llvm-svn: 147843 | 
| | 
| 
| 
| 
| 
| | AVX is now an SSE level and no longer disables SSE checks.
llvm-svn: 147842 | 
| | 
| 
| 
| 
| 
| | predicates. Another commit will remove orAVX functions from X86SubTarget.
llvm-svn: 147841 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | On Thumb, the displacement computation hardware uses the address of the
current instruction rouned down to a multiple of 4.  Include this
rounding in the UserOffset we compute for each instruction.
When inline asm is present, the instruction alignment may not be known.
Constrain the maximum displacement instead in that case.
This makes it possible for CreateNewWater() and OffsetIsInRange() to
agree about the valid displacements.  When they disagree, infinite
looping happens.
As always, test cases for this stuff are insane.
<rdar://problem/10660175>
llvm-svn: 147825 | 
| | 
| 
| 
| | llvm-svn: 147820 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | The pass is prone to looping, and it is better to crash than loop
forever, even in a -Asserts build.
<rdar://problem/10660175>
llvm-svn: 147806 | 
| | 
| 
| 
| | llvm-svn: 147805 | 
| | 
| 
| 
| 
| 
| 
| | AsmParser holds info specific to target parser.
AsmParserVariant holds info specific to asm variants supported by the target.
llvm-svn: 147787 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | this substraction will result in small negative numbers at worst which
become very large positive numbers on assignment and are thus caught by
the <=4 check on the next line. The >0 check clearly intended to catch
these as negative numbers.
Spotted by inspection, and impossible to trigger given the shift widths
that can be used.
llvm-svn: 147773 | 
| | 
| 
| 
| 
| 
| | Predicate functions have been altered to maintain previous names and behavior.
llvm-svn: 147770 | 
| | 
| 
| 
| | llvm-svn: 147769 | 
| | 
| 
| 
| 
| 
| | priority over the SSE version. Another step towards trying to remove the AVX hack that disables SSE from X86Subtarget.
llvm-svn: 147768 | 
| | 
| 
| 
| 
| 
| | on MOVNTPS and MOVNTDQ. And v4i64 was completely missing.
llvm-svn: 147767 | 
| | 
| 
| 
| 
| 
| | AVX equivalent so we should use the SSE version.
llvm-svn: 147766 | 
| | 
| 
| 
| 
| 
| | operations ANDPS/ORPS/XORPS/ANDNPS. This fixes a pattern ordering issue that meant that the SSE2 instructions could never be directly selected since the SSE1 patterns would always match first. This is largely moot with the ExeDepsFix pass, but I'm trying to audit for all such ordering issues.
llvm-svn: 147765 | 
| | 
| 
| 
| 
| 
| | hasXMM/hasXMMInt instead. Also fix one place that checked SSE3, but accidentally excluded AVX to use hasSSE3orAVX. This is a step towards removing the AVX hack from the X86Subtarget.h
llvm-svn: 147764 | 
| | 
| 
| 
| 
| 
| | instructions that were added along with SSE instructions to check for AVX in addition to SSE level.
llvm-svn: 147762 |