Skip to content
  1. Jan 01, 2014
  2. Dec 31, 2013
  3. Dec 30, 2013
  4. Dec 25, 2013
  5. Dec 20, 2013
    • 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
  6. Dec 19, 2013
    • Hal Finkel's avatar
      Add support for positionally-encoded operands to FixedLenDecoderEmitter · 71b2e20d
      Hal Finkel authored
      Unfortunately, the PowerPC instruction definitions make heavy use of the
      positional operand encoding heuristic to map operands onto bitfield variables
      in the instruction definitions. Changing this to use name-based mapping is not
      trivial, however, because additional infrastructure needs to be designed to
      handle mapping of complex operands (with multiple suboperands) onto multiple
      bitfield variables.
      
      In the mean time, this adds support for positionally encoded operands to
      FixedLenDecoderEmitter, so that we can generate a disassembler for the PowerPC
      backend. To prevent an accidental reliance on this feature, and to prevent an
      undesirable interaction with existing disassemblers, a backend must opt-in to
      this support by setting the new decodePositionallyEncodedOperands
      instruction-set bit to true.
      
      When enabled, this iterates the variables that contribute to the instruction
      encoding, just as the encoder does, and emulates the procedure the encoder uses
      to map "numbered" operands to variables. The bit range for each variable is
      also determined as the encoder determines them. This map is then consulted
      during the decoder-generator's loop over operands to decode, allowing the
      decoder to understand both position-based and name-based operand-to-variable
      mappings.
      
      As noted in the comment on the decodePositionallyEncodedOperands definition,
      this support should be removed once it is no longer needed. There should be no
      change to existing disassemblers.
      
      llvm-svn: 197691
      71b2e20d
    • Hal Finkel's avatar
      Add support for PointerLikeRegClass to FixedLenDecoderEmitter · 9d95e8d5
      Hal Finkel authored
      This is more prep for adding the PowerPC disassembler. FixedLenDecoderEmitter
      should recognize PointerLikeRegClass operands as register types, and generate
      register-like decoding calls instead of treating them like immediates.
      
      llvm-svn: 197680
      9d95e8d5
  7. Dec 17, 2013
    • Hal Finkel's avatar
      Support little-endian encodings in the FixedLenDecoderEmitter · 81e6fccb
      Hal Finkel authored
      The convention used to specify the PowerPC ISA is that bits are numbered in
      reverse order (0 is the index of the high bit). To support this "little endian"
      encoding convention, CodeEmitterGen will reverse the bit numberings prior to
      generating the encoding tables. In order to generate a disassembler,
      FixedLenDecoderEmitter needs to do the same.
      
      This moves the bit reversal logic out of CodeEmitterGen and into CodeGenTarget
      (where it can be used by both CodeEmitterGen and FixedLenDecoderEmitter). This
      is prep work for disassembly support in the PPC backend (which is the only
      in-tree user of this little-endian encoding support).
      
      llvm-svn: 197532
      81e6fccb
  8. Dec 16, 2013
  9. Dec 05, 2013
    • Alp Toker's avatar
      Correct word hyphenations · f907b891
      Alp Toker authored
      This patch tries to avoid unrelated changes other than fixing a few
      hyphen-related ambiguities and contractions in nearby lines.
      
      llvm-svn: 196471
      f907b891
  10. Dec 02, 2013
  11. Nov 19, 2013
  12. Nov 18, 2013
    • Alexey Samsonov's avatar
      Revert r194865 and r194874. · 49109a27
      Alexey Samsonov authored
      This change is incorrect. If you delete virtual destructor of both a base class
      and a subclass, then the following code:
        Base *foo = new Child();
        delete foo;
      will not cause the destructor for members of Child class. As a result, I observe
      plently of memory leaks. Notable examples I investigated are:
      ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
      
      llvm-svn: 194997
      49109a27
  13. Nov 17, 2013
  14. Nov 16, 2013
  15. Nov 15, 2013
  16. Nov 03, 2013
  17. Oct 31, 2013
  18. Oct 28, 2013
  19. Oct 20, 2013
  20. Oct 14, 2013
  21. Oct 12, 2013
  22. Oct 11, 2013
  23. Oct 10, 2013
  24. Oct 09, 2013
  25. Oct 08, 2013
  26. Oct 07, 2013
Loading