Skip to content
  1. May 14, 2013
    • Jyotsna Verma's avatar
      Hexagon: Pass to replace tranfer/copy instructions into combine instruction · 803e506f
      Jyotsna Verma authored
      where possible.
      
      llvm-svn: 181817
      803e506f
    • Eric Christopher's avatar
      Reapply "Subtract isn't commutative, fix this for MMX psub." with · b27cd8be
      Eric Christopher authored
      a somewhat randomly chosen cpu that will minimize cpu specific
      differences on bots.
      
      llvm-svn: 181814
      b27cd8be
    • Eric Christopher's avatar
      Temporarily revert "Subtract isn't commutative, fix this for MMX psub." · 3eee7454
      Eric Christopher authored
      It's causing failures on the atom bot.
      
      llvm-svn: 181812
      3eee7454
    • Rafael Espindola's avatar
      Fix __clear_cache declaration. · e16befb5
      Rafael Espindola authored
      This fixes the build with gcc in gnu++98 and gnu++11 mode.
      
      llvm-svn: 181811
      e16befb5
    • Eric Christopher's avatar
      Subtract isn't commutative, fix this for MMX psub. · 0344f495
      Eric Christopher authored
      Patch by Andrea DiBiagio.
      
      llvm-svn: 181809
      0344f495
    • Jakob Stoklund Olesen's avatar
      Recognize sparc64 as an alias for sparcv9 triples. · abc3d23c
      Jakob Stoklund Olesen authored
      Patch by Brad Smith!
      
      llvm-svn: 181808
      abc3d23c
    • Jyotsna Verma's avatar
      Hexagon: Add patterns to generate 'combine' instructions. · 2dca82ad
      Jyotsna Verma authored
      llvm-svn: 181805
      2dca82ad
    • Jyotsna Verma's avatar
      Hexagon: ArePredicatesComplement should not restrict itself to TFRs. · 11bd54af
      Jyotsna Verma authored
      llvm-svn: 181803
      11bd54af
    • Kai Nacke's avatar
      Add bitcast to store of personality function. · 9a224ced
      Kai Nacke authored
      The personality function is user defined and may have an arbitrary result type.
      The code assumes always i8*. This results in an assertion failure if a different
      type is used. A bitcast to i8* is added to prevent this failure.
      
      Reviewed by: Renato Golin, Bob Wilson
      
      llvm-svn: 181802
      9a224ced
    • Derek Schuff's avatar
      Fix ARM FastISel tests, as a first step to enabling ARM FastISel · bd7c6e50
      Derek Schuff authored
      ARM FastISel is currently only enabled for iOS non-Thumb1, and I'm working on
      enabling it for other targets. As a first step I've fixed some of the tests.
      Changes to ARM FastISel tests:
      - Different triples don't generate the same relocations (especially
        movw/movt versus constant pool loads). Use a regex to allow either.
      - Mangling is different. Use a regex to allow either.
      - The reserved registers are sometimes different, so registers get
        allocated in a different order. Capture the names only where this
        occurs.
      - Add -verify-machineinstrs to some tests where it works. It doesn't
        work everywhere it should yet.
      - Add -fast-isel-abort to many tests that didn't have it before.
      - Split out the VarArg test from fast-isel-call.ll into its own
        test. This simplifies test setup because of --check-prefix.
      
      Patch by JF Bastien
      
      llvm-svn: 181801
      bd7c6e50
    • Bill Schmidt's avatar
      PPC32: Fix stack collision between FP and CR save areas. · ef3d1a24
      Bill Schmidt authored
      The changes to CR spill handling missed a case for 32-bit PowerPC.
      The code in PPCFrameLowering::processFunctionBeforeFrameFinalized()
      checks whether CR spill has occurred using a flag in the function
      info.  This flag is only set by storeRegToStackSlot and
      loadRegFromStackSlot.  spillCalleeSavedRegisters does not call
      storeRegToStackSlot, but instead produces MI directly.  Thus we don't
      see the CR is spilled when assigning frame offsets, and the CR spill
      ends up colliding with some other location (generally the FP slot).
      
      This patch sets the flag in spillCalleeSavedRegisters for PPC32 so
      that the CR spill is properly detected and gets its own slot in the
      stack frame.
      
      llvm-svn: 181800
      ef3d1a24
    • Jyotsna Verma's avatar
      Hexagon: Test case to check if branch probabilities are properly reflected in · 7dcbb96e
      Jyotsna Verma authored
      the jump instructions in the form of taken/not-taken hint.
      
      llvm-svn: 181799
      7dcbb96e
    • Jyotsna Verma's avatar
      c61e350a
    • Tom Stellard's avatar
      R600/SI: Add processor type for Hainan asic · 1e21b530
      Tom Stellard authored
      
      
      Patch by: Alex Deucher
      
      Reviewed-by: default avatarTom Stellard <thomas.stellard@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      
      NOTE: This is a candidate for the 3.3 branch.
      llvm-svn: 181792
      1e21b530
    • Duncan Sands's avatar
      Get the unittests compiling when building with cmake and the setting · b33790d8
      Duncan Sands authored
      -DLLVM_ENABLE_THREADS=false.
      
      llvm-svn: 181788
      b33790d8
    • Rafael Espindola's avatar
      Declare __clear_cache. · 17268dc1
      Rafael Espindola authored
      GCC declares __clear_cache in the gnu modes (-std=gnu++98,
      -std=gnu++11), but not in the strict modes (-std=c++98, -std=c++11). This patch
      declares it and therefore fixes the build when using one of the strict modes.
      
      llvm-svn: 181785
      17268dc1
    • Richard Sandiford's avatar
      [SystemZ] Add disassembler support · eb9af294
      Richard Sandiford authored
      llvm-svn: 181777
      eb9af294
    • Michel Danzer's avatar
    • Richard Sandiford's avatar
      [SystemZ] Add extra testscases for r181773 · 18272f84
      Richard Sandiford authored
      Forgot to svn add these...
      
      llvm-svn: 181774
      18272f84
    • Richard Sandiford's avatar
      [SystemZ] Rework handling of constant PC-relative operands · 1fb5883d
      Richard Sandiford authored
      The GNU assembler treats things like:
      
              brasl   %r14, 100
      
      in the same way as:
      
              brasl   %r14, .+100
      
      rather than as a branch to absolute address 100.  We implemented this in
      LLVM by creating an immediate operand rather than the usual expr operand,
      and by handling immediate operands specially in the code emitter.
      This was undesirable for (at least) three reasons:
      
      - the specialness of immediate operands was exposed to the backend MC code,
        rather than being limited to the assembler parser.
      
      - in disassembly, an immediate operand really is an absolute address.
        (Note that this means reassembling printed disassembly can't recreate
        the original code.)
      
      - it would interfere with any assembly manipulation that we might
        try in future.  E.g. operations like branch shortening can change
        the relative position of instructions, but any code that updates
        sym+offset addresses wouldn't update an immediate "100" operand
        in the same way as an explicit ".+100" operand.
      
      This patch changes the implementation so that the assembler creates
      a "." label for immediate PC-relative operands, so that the operand
      to the MCInst is always the absolute address.  The patch also adds
      some error checking of the offset.
      
      llvm-svn: 181773
      1fb5883d
    • Richard Sandiford's avatar
      [SystemZ] Remove bogus isAsmParserOnly · 6a808f98
      Richard Sandiford authored
      Marking instructions as isAsmParserOnly stops them from being disassembled.
      However, in cases where separate asm and codegen versions exist, we actually
      want to disassemble to the asm ones.
      
      No functional change intended.
      
      llvm-svn: 181772
      6a808f98
    • Richard Sandiford's avatar
      [SystemZ] Match operands to fields by name rather than by order · 7d37cd26
      Richard Sandiford authored
      The SystemZ port currently relies on the order of the instruction operands
      matching the order of the instruction field lists.  This isn't desirable
      for disassembly, where the two are matched only by name.  E.g. the R1 and R2
      fields of an RR instruction should have corresponding R1 and R2 operands.
      
      The main complication is that addresses are compound operands,
      and as far as I know there is no mechanism to allow individual
      suboperands to be selected by name in "let Inst{...} = ..." assignments.
      Luckily it doesn't really matter though.  The SystemZ instruction
      encoding groups all address fields together in a predictable order,
      so it's just as valid to see the entire compound address operand as
      a single field.  That's the approach taken in this patch.
      
      Matching by name in turn means that the operands to COPY SIGN and
      CONVERT TO FIXED instructions can be given in natural order.
      (It was easier to do this at the same time as the rename,
      since otherwise the intermediate step was too confusing.)
      
      No functional change intended.
      
      llvm-svn: 181771
      7d37cd26
    • Richard Sandiford's avatar
      [SystemZ] Match operands to fields by name rather than by order · d454ec0c
      Richard Sandiford authored
      The SystemZ port currently relies on the order of the instruction operands
      matching the order of the instruction field lists.  This isn't desirable
      for disassembly, where the two are matched only by name.  E.g. the R1 and R2
      fields of an RR instruction should have corresponding R1 and R2 operands.
      
      The main complication is that addresses are compound operands,
      and as far as I know there is no mechanism to allow individual
      suboperands to be selected by name in "let Inst{...} = ..." assignments.
      Luckily it doesn't really matter though.  The SystemZ instruction
      encoding groups all address fields together in a predictable order,
      so it's just as valid to see the entire compound address operand as
      a single field.  That's the approach taken in this patch.
      
      Matching by name in turn means that the operands to COPY SIGN and
      CONVERT TO FIXED instructions can be given in natural order.
      (It was easier to do this at the same time as the rename,
      since otherwise the intermediate step was too confusing.)
      
      No functional change intended.
      
      llvm-svn: 181769
      d454ec0c
    • Michael Gottesman's avatar
      Removed trailing whitespace. · 0c8b5628
      Michael Gottesman authored
      llvm-svn: 181760
      0c8b5628
    • Reed Kotler's avatar
      Fix typo. · 821e86f0
      Reed Kotler authored
      llvm-svn: 181759
      821e86f0
    • Reed Kotler's avatar
      Removed an unnamed namespace and forgot to make two of the functions inside · cad47f02
      Reed Kotler authored
      "static".
      
      llvm-svn: 181754
      cad47f02
    • Reed Kotler's avatar
      This is the first of three patches which creates stubs used for · 2c4657d9
      Reed Kotler authored
      Mips16/32 floating point interoperability.
      
      When Mips16 code calls external functions that would normally have some
      of its parameters or return values passed in floating point registers,
      it needs (Mips32) helper functions to do this because while in Mips16 mode
      there is no ability to access the floating point registers.
      
      In Pic mode, this is done with a set of predefined functions in libc.
      This case is already handled in llvm for Mips16.
      
      In static relocation mode, for efficiency reasons, the compiler generates
      stubs that the linker will use if it turns out that the external function
      is a Mips32 function. (If it's Mips16, then it does not need the helper
      stubs).
      
      These stubs are identically named and the linker knows about these tricks
      and will not create multiple copies and will delete them if they are not
      needed.
      
      llvm-svn: 181753
      2c4657d9
    • Akira Hatanaka's avatar
      StackColoring: don't clear an instruction's mem operand if the underlying · 1f24e6a6
      Akira Hatanaka authored
      object is a PseudoSourceValue and PseudoSourceValue::isConstant returns true (i.e.,
      points to memory that has a constant value).
      
      llvm-svn: 181751
      1f24e6a6
    • David Blaikie's avatar
      Assert that DIEEntries are constructed with non-null DIEs · 7b770c6a
      David Blaikie authored
      This just brings a crash a little further forward from DWARF emission to
      DIE construction to make errors easier to diagnose.
      
      llvm-svn: 181748
      7b770c6a
    • Arnold Schwaighofer's avatar
      LoopVectorize: Handle loops with multiple forward inductions · 2e7a922a
      Arnold Schwaighofer authored
      We used to give up if we saw two integer inductions. After this patch, we base
      further induction variables on the chosen one like we do in the reverse
      induction and pointer induction case.
      
      Fixes PR15720.
      
      radar://13851975
      
      llvm-svn: 181746
      2e7a922a
    • Michael Gottesman's avatar
    • Michael Gottesman's avatar
      [objc-arc-opts] In the presense of an alloca unconditionally remove RR pairs... · a76143ee
      Michael Gottesman authored
      [objc-arc-opts] In the presense of an alloca unconditionally remove RR pairs if and only if we are both KnownSafeBU/KnownSafeTD rather than just either or.
      
      In the presense of a block being initialized, the frontend will emit the
      objc_retain on the original pointer and the release on the pointer loaded from
      the alloca. The optimizer will through the provenance analysis realize that the
      two are related (albiet different), but since we only require KnownSafe in one
      direction, will match the inner retain on the original pointer with the guard
      release on the original pointer. This is fixed by ensuring that in the presense
      of allocas we only unconditionally remove pointers if both our retain and our
      release are KnownSafe (i.e. we are KnownSafe in both directions) since we must
      deal with the possibility that the frontend will emit what (to the optimizer)
      appears to be unbalanced retain/releases.
      
      An example of the miscompile is:
      
        %A = alloca
        retain(%x)
        retain(%x) <--- Inner Retain
        store %x, %A
        %y = load %A
        ... DO STUFF ...
        release(%y)
        call void @use(%x)
        release(%x) <--- Guarding Release
      
      getting optimized to:
      
        %A = alloca
        retain(%x)
        store %x, %A
        %y = load %A
        ... DO STUFF ...
        release(%y)
        call void @use(%x)
      
      rdar://13750319
      
      llvm-svn: 181743
      a76143ee
  2. May 13, 2013
Loading