Skip to content
  1. Dec 26, 2013
  2. Dec 25, 2013
  3. Dec 24, 2013
  4. Dec 23, 2013
  5. Dec 22, 2013
  6. Dec 20, 2013
    • Lang Hames's avatar
      ARM AnalyzeBranch should ignore DEBUG_VALUES while analyzing terminators. · 18c98a58
      Lang Hames authored
      Found by inspection by Julien Lerouge. Thanks Julian!
      
      llvm-svn: 197833
      18c98a58
    • Timur Iskhodzhanov's avatar
      c1fb2d61
    • Roman Divacky's avatar
      Implement initial-exec TLS for PPC32. · 32143e2b
      Roman Divacky authored
      llvm-svn: 197824
      32143e2b
    • Zoran Jovanovic's avatar
      Support for microMIPS FPU instructions 1. · ce02486d
      Zoran Jovanovic authored
      llvm-svn: 197815
      ce02486d
    • Richard Sandiford's avatar
      [SystemZ] Optimize comparisons with truncated extended loads · 83a0b6ab
      Richard Sandiford authored
      If the extension of a loaded value is compared against zero and used in
      other arithmetic, InstCombine will change the comparison to use the
      unextended load.  It's also possible that the comparison could be against
      the unextended load from the outset.
      
      In DAG form this becomes a truncation of an extending load.  We want to
      strip the truncation if possible so that we can use load-and-test instructions.
      
      llvm-svn: 197804
      83a0b6ab
    • Richard Sandiford's avatar
      [SystemZ] Extend RISBG optimization · 220ee49b
      Richard Sandiford authored
      The handling of ANY_EXTEND and ZERO_EXTEND was too strict.  In this context
      we can treat ZERO_EXTEND in much the same way as an AND and then also handle
      outermost ZERO_EXTENDs.
      
      I couldn't find a test that benefited from the ANY_EXTEND change, but it's
      more obvious to write it this way once SIGN_EXTEND and ZERO_EXTEND are
      handled differently.
      
      llvm-svn: 197802
      220ee49b
    • Saleem Abdulrasool's avatar
      ARM IAS: add support for the .pool directive · 6e6c239e
      Saleem Abdulrasool authored
      The .pool directive is an alias for the .ltorg directive used to create a
      literal pool.  Simply treat .pool as if .ltorg was passed.
      
      llvm-svn: 197787
      6e6c239e
    • Tom Stellard's avatar
      R600: Allow ftrunc · eddfa694
      Tom Stellard authored
      
      
      v2: Add ftrunc->TRUNC pattern instead of replacing int_AMDGPU_trunc
      v3: move ftrunc pattern next to TRUNC definition, it's available since R600
      
      Patch By: Jan Vesely
      
      Reviewed-by: default avatarTom Stellard <thomas.stellard@amd.com>
      Signed-off-by: default avatarJan Vesely <jan.vesely@rutgers.edu>
      llvm-svn: 197783
      eddfa694
    • Eric Christopher's avatar
      [x86] Rename In32BitMode predicate to Not64BitMode · c0a5aaea
      Eric Christopher authored
      That's what it actually means, and with 16-bit support it's going to be
      a little more relevant since in a few corner cases we may actually want
      to distinguish between 16-bit and 32-bit mode (for example the bare 'push'
      aliases to pushw/pushl etc.)
      
      Patch by David Woodhouse
      
      llvm-svn: 197768
      c0a5aaea
    • Alp Toker's avatar
      Fix documentation typos · 171b0c36
      Alp Toker authored
      llvm-svn: 197757
      171b0c36
    • Kevin Enderby's avatar
      Un-revert: the buildbot failure in LLVM on lld-x86_64-win7 had me with · 36eba25f
      Kevin Enderby authored
      this commit as the only one on the Blamelist so I quickly reverted this.
      However it was actually Nick's change who has since fixed that issue.
      
      Original commit message:
      
      Changed the X86 assembler for intel syntax to work with directional labels.
      
      The X86 assembler as a separate code to parser the intel assembly syntax
      in X86AsmParser::ParseIntelOperand().  This did not parse directional labels.
      And if something like 1f was used as a branch target it would get an
      "Unexpected token" error.
      
      The fix starts in X86AsmParser::ParseIntelExpression() in the case for
      AsmToken::Integer, it needs to grab the IntVal from the current token
      then look for a 'b' or 'f' following an Integer.  Then it basically needs to
      do what is done in AsmParser::parsePrimaryExpr() for directional
      labels.  It saves the MCExpr it creates in the IntelExprStateMachine
      in the Sym field.
      
      When it returns to X86AsmParser::ParseIntelOperand() it looks
      for a non-zero Sym field in the IntelExprStateMachine and if
      set it creates a memory operand not an immediate operand
      it would normally do for the Integer.
      
      rdar://14961158
      
      llvm-svn: 197744
      36eba25f
  7. Dec 19, 2013
    • David Peixotto's avatar
      Ensure deterministic when printing ARM assembler constant pools · 52303f6e
      David Peixotto authored
      We dump any non-empty assembler constant pools after a successful
      parse of an assembly file that uses the ldr pseudo opcode. These
      per-section constant pools should be output in a deterministic order
      to ensure that we always generate the same output when printing the
      output with an AsmStreamer.
      
      This patch changes the map data struture used to associate a section
      with its constant pool to a MapVector to ensure deterministic
      output. Because this map type does not support deletion, we now
      check that the constant pool is not empty before dumping its entries
      and clear the entries after emitting them with the streamer.
      
      llvm-svn: 197735
      52303f6e
    • Kevin Enderby's avatar
      Revert my change to the X86 assembler for intel syntax to work with · d6f2a637
      Kevin Enderby authored
      directional labels.  Because it doesn't work for windows :)
      
      llvm-svn: 197731
      d6f2a637
    • Kevin Enderby's avatar
      Changed the X86 assembler for intel syntax to work with directional labels. · 592d3ac2
      Kevin Enderby authored
      The X86 assembler has a separate code to parser the intel assembly syntax
      in X86AsmParser::ParseIntelOperand().  This did not parse directional labels.
      And if something like 1f was used as a branch target it would get an
      "Unexpected token" error.
      
      The fix starts in X86AsmParser::ParseIntelExpression() in the case for
      AsmToken::Integer, it needs to grab the IntVal from the current token
      then look for a 'b' or 'f' following the Integer.  Then it basically needs to
      do what is done in AsmParser::parsePrimaryExpr() for directional
      labels.  It saves the MCExpr it creates in the IntelExprStateMachine
      in the Sym field.
      
      When it returns to X86AsmParser::ParseIntelOperand() it looks
      for a non-zero Sym field in the IntelExprStateMachine and if
      set it creates a memory operand not an immediate operand
      it would normally do for the Integer.
      
      rdar://14961158
      
      llvm-svn: 197728
      592d3ac2
    • Quentin Colombet's avatar
      [X86][fast-isel] Fix select lowering. · 90a646e4
      Quentin Colombet authored
      The condition in selects is supposed to be i1.
      Make sure we are just reading the less significant bit
      of the 8 bits width value to match this constraint.
      
      <rdar://problem/15651765>
      
      llvm-svn: 197712
      90a646e4
    • David Peixotto's avatar
      Implement the .ltorg directive for ARM assembly · 80c083a6
      David Peixotto authored
      This directive will write out the assembler-maintained constant
      pool for the current section. These constant pools are created to
      support the ldr-pseudo instruction (e.g. ldr r0, =val).
      
      The directive can be used by the programmer to place the constant
      pool in a location that can be reached by a pc-relative offset in
      the ldr instruction.
      
      llvm-svn: 197711
      80c083a6
    • David Peixotto's avatar
      Implement the ldr-pseudo opcode for ARM assembly · e407d093
      David Peixotto authored
      The ldr-pseudo opcode is a convenience for loading 32-bit constants.
      It is converted into a pc-relative load from a constant pool. For
      example,
      
        ldr r0, =0x10001
        ldr r1, =bar
      
      will generate this output in the final assembly
      
        ldr r0, .Ltmp0
        ldr r1, .Ltmp1
        ...
        .Ltmp0: .long 0x10001
        .Ltmp1: .long bar
      
      Sketch of the LDR pseudo implementation:
        Keep a map from Section => ConstantPool
      
        When parsing ldr r0, =val
          parse val as an MCExpr
          get ConstantPool for current Section
          Label = CreateTempSymbol()
          remember val in ConstantPool at next free slot
          add operand to ldr that is MCSymbolRef of Label
      
        On finishParse() callback
          Write out all non-empty constant pools
          for each Entry in ConstantPool
            Emit Entry.Label
            Emit Entry.Value
      
      Possible improvements to be added in a later patch:
        1. Does not convert load of small constants to mov
           (e.g. ldr r0, =0x1 => mov r0, 0x1)
        2. Does reuse constant pool entries for same constant
      
      The implementation was tested for ARM, Thumb1, and Thumb2 targets on
      linux and darwin.
      
      llvm-svn: 197708
      e407d093
    • Rafael Espindola's avatar
      Small simplification, p0 is the same as p. · 4fa79758
      Rafael Espindola authored
      llvm-svn: 197699
      4fa79758
Loading