<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/TableGen/BigEncoder.td, branch users/nico/python-2</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>Change range operator from deprecated '-' to '...'</title>
<updated>2020-09-12T20:26:32+00:00</updated>
<author>
<name>Paul C. Anagnostopoulos</name>
<email>paul@windfall.com</email>
</author>
<published>2020-09-11T13:49:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e8e3693ceaa1afe267f21d2ba8d9565ea8fe7c12'/>
<id>e8e3693ceaa1afe267f21d2ba8d9565ea8fe7c12</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix compile-time regression caused by rL371928</title>
<updated>2019-09-18T18:14:42+00:00</updated>
<author>
<name>Daniel Sanders</name>
<email>daniel_l_sanders@apple.com</email>
</author>
<published>2019-09-18T18:14:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1723364a68487c1c070ca58799a0a5c39adca85d'/>
<id>1723364a68487c1c070ca58799a0a5c39adca85d</id>
<content type='text'>
Summary:
Also fixup rL371928 for cases that occur on our out-of-tree backend

There were still quite a few intermediate APInts and this caused the
compile time of MCCodeEmitter for our target to jump from 16s up to
~5m40s. This patch, brings it back down to ~17s by eliminating pretty
much all of them using two new APInt functions (extractBitsAsZExtValue(),
insertBits() but with a uint64_t). The exact conditions for eliminating
them is that the field extracted/inserted must be &lt;=64-bit which is
almost always true.

Note: The two new APInt API's assume that APInt::WordSize is at least
64-bit because that means they touch at most 2 APInt words. They
statically assert that's true. It seems very unlikely that someone
is patching it to be smaller so this should be fine.

Reviewers: jmolloy

Reviewed By: jmolloy

Subscribers: hiraditya, dexonsmith, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D67686

llvm-svn: 372243
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
Also fixup rL371928 for cases that occur on our out-of-tree backend

There were still quite a few intermediate APInts and this caused the
compile time of MCCodeEmitter for our target to jump from 16s up to
~5m40s. This patch, brings it back down to ~17s by eliminating pretty
much all of them using two new APInt functions (extractBitsAsZExtValue(),
insertBits() but with a uint64_t). The exact conditions for eliminating
them is that the field extracted/inserted must be &lt;=64-bit which is
almost always true.

Note: The two new APInt API's assume that APInt::WordSize is at least
64-bit because that means they touch at most 2 APInt words. They
statically assert that's true. It seems very unlikely that someone
is patching it to be smaller so this should be fine.

Reviewers: jmolloy

Reviewed By: jmolloy

Subscribers: hiraditya, dexonsmith, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D67686

llvm-svn: 372243
</pre>
</div>
</content>
</entry>
<entry>
<title>[CodeEmitter] Improve testing for APInt encoding</title>
<updated>2019-09-15T08:44:40+00:00</updated>
<author>
<name>James Molloy</name>
<email>jmolloy@google.com</email>
</author>
<published>2019-09-15T08:44:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a088b95f89176b87553d68f3ffbe1f7cba4cefb5'/>
<id>a088b95f89176b87553d68f3ffbe1f7cba4cefb5</id>
<content type='text'>
I missed Artem's comment in D67487 before committing.

Differential Revision: https://reviews.llvm.org/D67487

llvm-svn: 371929
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I missed Artem's comment in D67487 before committing.

Differential Revision: https://reviews.llvm.org/D67487

llvm-svn: 371929
</pre>
</div>
</content>
</entry>
<entry>
<title>[CodeEmitter] Support instruction widths &gt; 64 bits</title>
<updated>2019-09-15T08:35:08+00:00</updated>
<author>
<name>James Molloy</name>
<email>jmolloy@google.com</email>
</author>
<published>2019-09-15T08:35:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=60aadd19cbffc3793476a14d2e3529214119e2f5'/>
<id>60aadd19cbffc3793476a14d2e3529214119e2f5</id>
<content type='text'>
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).

This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is &gt; 64 bits (NFC for existing targets).

When Inst.BitWidth &gt; 64 the prototype changes to:

  void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &amp;MI,
                                                  SmallVectorImpl&lt;MCFixup&gt; &amp;Fixups,
                                                  APInt &amp;Inst,
                                                  APInt &amp;Scratch,
                                                  const MCSubtargetInfo &amp;STI);

The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.

Similarly the operand encoding prototype changes to:

  getMachineOpValue(const MCInst &amp;MI, const MCOperand &amp;MO, APInt &amp;op, SmallVectorImpl&lt;MCFixup&gt; &amp;Fixups, const MCSubtargetInfo &amp;STI);

That is, the operand is passed by reference as APInt rather than returned as uint64_t.

To reiterate, this APInt mode is enabled only when Inst.BitWidth &gt; 64, so this change is NFC for existing targets.

llvm-svn: 371928
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).

This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is &gt; 64 bits (NFC for existing targets).

When Inst.BitWidth &gt; 64 the prototype changes to:

  void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &amp;MI,
                                                  SmallVectorImpl&lt;MCFixup&gt; &amp;Fixups,
                                                  APInt &amp;Inst,
                                                  APInt &amp;Scratch,
                                                  const MCSubtargetInfo &amp;STI);

The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.

Similarly the operand encoding prototype changes to:

  getMachineOpValue(const MCInst &amp;MI, const MCOperand &amp;MO, APInt &amp;op, SmallVectorImpl&lt;MCFixup&gt; &amp;Fixups, const MCSubtargetInfo &amp;STI);

That is, the operand is passed by reference as APInt rather than returned as uint64_t.

To reiterate, this APInt mode is enabled only when Inst.BitWidth &gt; 64, so this change is NFC for existing targets.

llvm-svn: 371928
</pre>
</div>
</content>
</entry>
</feed>
