Skip to content
  1. Jun 08, 2008
  2. Jun 06, 2008
    • Duncan Sands's avatar
      Wrap MVT::ValueType in a struct to get type safety · 13237ac3
      Duncan Sands authored
      and better control the abstraction.  Rename the type
      to MVT.  To update out-of-tree patches, the main
      thing to do is to rename MVT::ValueType to MVT, and
      rewrite expressions like MVT::getSizeInBits(VT) in
      the form VT.getSizeInBits().  Use VT.getSimpleVT()
      to extract a MVT::SimpleValueType for use in switch
      statements (you will get an assert failure if VT is
      an extended value type - these shouldn't exist after
      type legalization).
      This results in a small speedup of codegen and no
      new testsuite failures (x86-64 linux).
      
      llvm-svn: 52044
      13237ac3
    • Zhou Sheng's avatar
      As Chris suggested, handle the situation if ShAmt larger than BitWidth, · 1152ca91
      Zhou Sheng authored
      otherwise, opt might crash.
      
      llvm-svn: 52041
      1152ca91
  3. Jun 05, 2008
  4. Jun 04, 2008
    • Owen Anderson's avatar
      Remove unneeded #include. · 61c7f2a6
      Owen Anderson authored
      llvm-svn: 51955
      61c7f2a6
    • Duncan Sands's avatar
      Change packed struct layout so that field sizes · fc3c489b
      Duncan Sands authored
      are the same as in unpacked structs, only field
      positions differ.  This only matters for structs
      containing x86 long double or an apint; it may
      cause backwards compatibility problems if someone
      has bitcode containing a packed struct with a
      field of one of those types.
      The issue is that only 10 bytes are needed to
      hold an x86 long double: the store size is 10
      bytes, but the ABI size is 12 or 16 bytes (linux/
      darwin) which comes from rounding the store size
      up by the alignment.  Because it seemed silly not
      to pack an x86 long double into 10 bytes in a
      packed struct, this is what was done.  I now
      think this was a mistake.  Reserving the ABI size
      for an x86 long double field even in a packed
      struct makes things more uniform: the ABI size is
      now always used when reserving space for a type.
      This means that developers are less likely to
      make mistakes.  It also makes life easier for the
      CBE which otherwise could not represent all LLVM
      packed structs (PR2402).
      Front-end people might need to adjust the way
      they create LLVM structs - see following change
      to llvm-gcc.
      
      llvm-svn: 51928
      fc3c489b
  5. Jun 03, 2008
  6. Jun 02, 2008
  7. Jun 01, 2008
    • Owen Anderson's avatar
      Don't remove the memcpy when call slot substitution fails. · d071a870
      Owen Anderson authored
      llvm-svn: 51848
      d071a870
    • Duncan Sands's avatar
      When simplifying a call to a bitcast function, tighten up · 0397cd2e
      Duncan Sands authored
      the conditions for performing the transform when only the
      function declaration is available: no longer allow turning
      i32 into i64 for example.  Only allow changing between
      pointer types, and between pointer types and integers of
      the same size.  For return values ptr -> intptr was already
      allowed; I added ptr -> ptr and intptr -> ptr while there.
      As shown by a recent objc testcase, changing the way
      parameters/return values are passed can be fatal when calling
      code written in assembler that directly manipulates call
      arguments and return values unless the transform has no
      impact on the way they are passed at the codegen level.
      While it is possible to imagine an ABI that treats integers
      of pointer size differently to pointers, I don't think LLVM
      supports any so the transform should now be safe while still
      being useful.
      
      llvm-svn: 51834
      0397cd2e
  8. May 31, 2008
  9. May 29, 2008
  10. May 28, 2008
  11. May 27, 2008
  12. May 25, 2008
  13. May 24, 2008
  14. May 23, 2008
Loading