<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/test/CodeGen/PowerPC/ppc64-stackmap.ll, 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>Obsolete WebKit Calling Convention (#71567)</title>
<updated>2023-11-09T17:08:41+00:00</updated>
<author>
<name>Juergen Ributzka</name>
<email>juergen@ributzka.de</email>
</author>
<published>2023-11-09T17:08:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6d1d7be1335c68aa93b3fe428791a3a4b99d63bc'/>
<id>6d1d7be1335c68aa93b3fe428791a3a4b99d63bc</id>
<content type='text'>
The WebKit Calling Convention was created specifically for the WebKit
FTL. FTL
doesn't use LLVM anymore and therefore this calling convention is
obsolete.

This commit removes the WebKit CC, its associated tests, and
documentation.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The WebKit Calling Convention was created specifically for the WebKit
FTL. FTL
doesn't use LLVM anymore and therefore this calling convention is
obsolete.

This commit removes the WebKit CC, its associated tests, and
documentation.</pre>
</div>
</content>
</entry>
<entry>
<title>Migrate llvm.experimental.patchpoint() to ptr.</title>
<updated>2022-08-10T12:18:02+00:00</updated>
<author>
<name>Edd Barrett</name>
<email>vext01@gmail.com</email>
</author>
<published>2022-08-10T12:13:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=fa250250b2966613fba7b88575029eb7cf0da66c'/>
<id>fa250250b2966613fba7b88575029eb7cf0da66c</id>
<content type='text'>
This intrinsic used a typed pointer for a call target operand. This
change updates the operand to be an opaque pointer and updates all
pointers in all test files that use the intrinsic.

Differential revision: https://reviews.llvm.org/D131261
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This intrinsic used a typed pointer for a call target operand. This
change updates the operand to be an opaque pointer and updates all
pointers in all test files that use the intrinsic.

Differential revision: https://reviews.llvm.org/D131261
</pre>
</div>
</content>
</entry>
<entry>
<title>Test stackmap support for floating point types.</title>
<updated>2022-05-30T09:49:32+00:00</updated>
<author>
<name>Edd Barrett</name>
<email>vext01@gmail.com</email>
</author>
<published>2022-05-30T09:18:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d245974e1a7809f40d994548b46b4694f247fc99'/>
<id>d245974e1a7809f40d994548b46b4694f247fc99</id>
<content type='text'>
It appears that float support is complete, or at least, the stackmap records
emitted are not inconceivable (I must admit that I don't know about many of the
architectures under test here).

One curiosity, the SystemZ tests highlight an undocumented (or maybe incorrect)
quirk of the stackmap format: in the case of a Register record, the Offset or
SmallConstant field can encode a sub-register index! I've only ever seen this
field zero for Register entries up until now.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It appears that float support is complete, or at least, the stackmap records
emitted are not inconceivable (I must admit that I don't know about many of the
architectures under test here).

One curiosity, the SystemZ tests highlight an undocumented (or maybe incorrect)
quirk of the stackmap format: in the case of a Register record, the Offset or
SmallConstant field can encode a sub-register index! I've only ever seen this
field zero for Register entries up until now.
</pre>
</div>
</content>
</entry>
<entry>
<title>Test stackmap support for i128</title>
<updated>2022-05-23T10:56:24+00:00</updated>
<author>
<name>Edd Barrett</name>
<email>vext01@gmail.com</email>
</author>
<published>2022-05-23T10:18:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=c5e5cf12583895396269f2a56c78e4464bd143da'/>
<id>c5e5cf12583895396269f2a56c78e4464bd143da</id>
<content type='text'>
This diff adds tests that check the currently-working stackmap cases for i128.
This will help ensure no regressions are later introduced by D125680 (when
ready).

Note that i128 stackmap support is currently incomplete, so we cant test all
i128 functionality:

    i128 constants &gt;= 2^{63} crash LLVM
    non-constant i128s crash LLVM

So this change tests only constant i128 operands of value &lt; 2^{63}.

A couple of incorrect comments are also fixed.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This diff adds tests that check the currently-working stackmap cases for i128.
This will help ensure no regressions are later introduced by D125680 (when
ready).

Note that i128 stackmap support is currently incomplete, so we cant test all
i128 functionality:

    i128 constants &gt;= 2^{63} crash LLVM
    non-constant i128s crash LLVM

So this change tests only constant i128 operands of value &lt; 2^{63}.

A couple of incorrect comments are also fixed.
</pre>
</div>
</content>
</entry>
<entry>
<title>[PowerPC] Fix machine verify pass error for PATCHPOINT pseudo instruction that bad machine code</title>
<updated>2018-12-30T15:13:51+00:00</updated>
<author>
<name>Kang Zhang</name>
<email>shkzhang@cn.ibm.com</email>
</author>
<published>2018-12-30T15:13:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9d78c60bf425b077d7f694a7508989ab889c7f53'/>
<id>9d78c60bf425b077d7f694a7508989ab889c7f53</id>
<content type='text'>
Summary:
For SDAG, we pretend patchpoints aren't special at all until we emit the code for the pseudo.
Then the verifier runs and it seems like we have a use of an undefined register (the register will 
be reserved later, but the verifier doesn't know that).

So this patch call setUsesTOCBasePtr before emit the code for the pseudo, so verifier can know 
X2 is a reserved register.

Reviewed By: nemanjai

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

llvm-svn: 350165
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
For SDAG, we pretend patchpoints aren't special at all until we emit the code for the pseudo.
Then the verifier runs and it seems like we have a use of an undefined register (the register will 
be reserved later, but the verifier doesn't know that).

So this patch call setUsesTOCBasePtr before emit the code for the pseudo, so verifier can know 
X2 is a reserved register.

Reviewed By: nemanjai

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

llvm-svn: 350165
</pre>
</div>
</content>
</entry>
<entry>
<title>[StackMaps] Increase the size of the "location size" field</title>
<updated>2017-04-28T04:48:42+00:00</updated>
<author>
<name>Sanjoy Das</name>
<email>sanjoy@playingwithpointers.com</email>
</author>
<published>2017-04-28T04:48:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ba0daee6b236cfda7488c68a1f16d51b6a60d521'/>
<id>ba0daee6b236cfda7488c68a1f16d51b6a60d521</id>
<content type='text'>
Summary:
In some cases LLVM (especially the SLP vectorizer) will create vectors
that are 256 bytes (or larger).  Given that this is intentional[0] is
likely to get more common, this patch updates the StackMap binary
format to deal with the spill locations for said vectors.

This change also bumps the stack map version from 2 to 3.

[0]: https://reviews.llvm.org/D32533#738350

Reviewers: reames, kavon, skatkov, javed.absar

Subscribers: mcrosier, nemanjai, llvm-commits

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

llvm-svn: 301615
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
In some cases LLVM (especially the SLP vectorizer) will create vectors
that are 256 bytes (or larger).  Given that this is intentional[0] is
likely to get more common, this patch updates the StackMap binary
format to deal with the spill locations for said vectors.

This change also bumps the stack map version from 2 to 3.

[0]: https://reviews.llvm.org/D32533#738350

Reviewers: reames, kavon, skatkov, javed.absar

Subscribers: mcrosier, nemanjai, llvm-commits

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

llvm-svn: 301615
</pre>
</div>
</content>
</entry>
<entry>
<title>[Stackmap] Added callsite counts to emitted function information.</title>
<updated>2016-09-14T20:22:03+00:00</updated>
<author>
<name>Sanjoy Das</name>
<email>sanjoy@playingwithpointers.com</email>
</author>
<published>2016-09-14T20:22:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=23f06e53d8c2febb80192f6ff93bce78a6af011d'/>
<id>23f06e53d8c2febb80192f6ff93bce78a6af011d</id>
<content type='text'>
Summary:
It was previously not possible for tools to use solely the stackmap
information emitted to reconstruct the return addresses of callsites in
the map, which is necessary to use the information to walk a stack. This
patch adds per-function callsite counts when emitting the stackmap
section in order to resolve the problem. Note that this slightly alters
the stackmap format, so external tools parsing these maps will need to
be updated.

**Problem Details:**
Records only store their offset from the beginning of the function they
belong to. While these records and the functions are output in program
order, it is not possible to determine where the end of one function's
records are without the callsite count when processing the records to
compute return addresses.

Patch by Kavon Farvardin!

Reviewers: atrick, ributzka, sanjoy

Subscribers: nemanjai

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

llvm-svn: 281532
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
It was previously not possible for tools to use solely the stackmap
information emitted to reconstruct the return addresses of callsites in
the map, which is necessary to use the information to walk a stack. This
patch adds per-function callsite counts when emitting the stackmap
section in order to resolve the problem. Note that this slightly alters
the stackmap format, so external tools parsing these maps will need to
be updated.

**Problem Details:**
Records only store their offset from the beginning of the function they
belong to. While these records and the functions are output in program
order, it is not possible to determine where the end of one function's
records are without the callsite count when processing the records to
compute return addresses.

Patch by Kavon Farvardin!

Reviewers: atrick, ributzka, sanjoy

Subscribers: nemanjai

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

llvm-svn: 281532
</pre>
</div>
</content>
</entry>
<entry>
<title>[PowerPC] Use the ABI indirect-call protocol for patchpoints</title>
<updated>2015-07-14T22:26:06+00:00</updated>
<author>
<name>Hal Finkel</name>
<email>hfinkel@anl.gov</email>
</author>
<published>2015-07-14T22:26:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9bbad03b9887e41bc0d5dccecc01237f39022102'/>
<id>9bbad03b9887e41bc0d5dccecc01237f39022102</id>
<content type='text'>
We used to take the address specified as the direct target of the patchpoint
and did no TOC-pointer handling.  This, however, as not all that useful,
because MCJIT tends to create a lot of modules, and they have their own TOC
sections. Thus, to call from the generated code to other generated code, you
really need to switch TOC pointers. Make this work as expected, and under
ELFv1, tread the address as the function descriptor address so that the correct
TOC pointer can be loaded.

llvm-svn: 242217
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We used to take the address specified as the direct target of the patchpoint
and did no TOC-pointer handling.  This, however, as not all that useful,
because MCJIT tends to create a lot of modules, and they have their own TOC
sections. Thus, to call from the generated code to other generated code, you
really need to switch TOC pointers. Make this work as expected, and under
ELFv1, tread the address as the function descriptor address so that the correct
TOC pointer can be loaded.

llvm-svn: 242217
</pre>
</div>
</content>
</entry>
<entry>
<title>[opaque pointer type] Add textual IR support for explicit type parameter to the call instruction</title>
<updated>2015-04-16T23:24:18+00:00</updated>
<author>
<name>David Blaikie</name>
<email>dblaikie@gmail.com</email>
</author>
<published>2015-04-16T23:24:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=23af64846f29e8249c717cad08ae64afc2ba647b'/>
<id>23af64846f29e8249c717cad08ae64afc2ba647b</id>
<content type='text'>
See r230786 and r230794 for similar changes to gep and load
respectively.

Call is a bit different because it often doesn't have a single explicit
type - usually the type is deduced from the arguments, and just the
return type is explicit. In those cases there's no need to change the
IR.

When that's not the case, the IR usually contains the pointer type of
the first operand - but since typed pointers are going away, that
representation is insufficient so I'm just stripping the "pointerness"
of the explicit type away.

This does make the IR a bit weird - it /sort of/ reads like the type of
the first operand: "call void () %x(" but %x is actually of type "void
()*" and will eventually be just of type "ptr". But this seems not too
bad and I don't think it would benefit from repeating the type
("void (), void () * %x(" and then eventually "void (), ptr %x(") as has
been done with gep and load.

This also has a side benefit: since the explicit type is no longer a
pointer, there's no ambiguity between an explicit type and a function
that returns a function pointer. Previously this case needed an explicit
type (eg: a function returning a void() function was written as
"call void () () * @x(" rather than "call void () * @x(" because of the
ambiguity between a function returning a pointer to a void() function
and a function returning void).

No ambiguity means even function pointer return types can just be
written alone, without writing the whole function's type.

This leaves /only/ the varargs case where the explicit type is required.

Given the special type syntax in call instructions, the regex-fu used
for migration was a bit more involved in its own unique way (as every
one of these is) so here it is. Use it in conjunction with the apply.sh
script and associated find/xargs commands I've provided in rr230786 to
migrate your out of tree tests. Do let me know if any of this doesn't
cover your cases &amp; we can iterate on a more general script/regexes to
help others with out of tree tests.

About 9 test cases couldn't be automatically migrated - half of those
were functions returning function pointers, where I just had to manually
delete the function argument types now that we didn't need an explicit
function type there. The other half were typedefs of function types used
in calls - just had to manually drop the * from those.

import fileinput
import sys
import re

pat = re.compile(r'((?:=|:|^|\s)call\s(?:[^@]*?))(\s*$|\s*(?:(?:\[\[[a-zA-Z0-9_]+\]\]|[@%](?:(")?[\\\?@a-zA-Z0-9_.]*?(?(3)"|)|{{.*}}))(?:\(|$)|undef|inttoptr|bitcast|null|asm).*$)')
addrspace_end = re.compile(r"addrspace\(\d+\)\s*\*$")
func_end = re.compile("(?:void.*|\)\s*)\*$")

def conv(match, line):
  if not match or re.search(addrspace_end, match.group(1)) or not re.search(func_end, match.group(1)):
    return line
  return line[:match.start()] + match.group(1)[:match.group(1).rfind('*')].rstrip() + match.group(2) + line[match.end():]

for line in sys.stdin:
  sys.stdout.write(conv(re.search(pat, line), line))

llvm-svn: 235145
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
See r230786 and r230794 for similar changes to gep and load
respectively.

Call is a bit different because it often doesn't have a single explicit
type - usually the type is deduced from the arguments, and just the
return type is explicit. In those cases there's no need to change the
IR.

When that's not the case, the IR usually contains the pointer type of
the first operand - but since typed pointers are going away, that
representation is insufficient so I'm just stripping the "pointerness"
of the explicit type away.

This does make the IR a bit weird - it /sort of/ reads like the type of
the first operand: "call void () %x(" but %x is actually of type "void
()*" and will eventually be just of type "ptr". But this seems not too
bad and I don't think it would benefit from repeating the type
("void (), void () * %x(" and then eventually "void (), ptr %x(") as has
been done with gep and load.

This also has a side benefit: since the explicit type is no longer a
pointer, there's no ambiguity between an explicit type and a function
that returns a function pointer. Previously this case needed an explicit
type (eg: a function returning a void() function was written as
"call void () () * @x(" rather than "call void () * @x(" because of the
ambiguity between a function returning a pointer to a void() function
and a function returning void).

No ambiguity means even function pointer return types can just be
written alone, without writing the whole function's type.

This leaves /only/ the varargs case where the explicit type is required.

Given the special type syntax in call instructions, the regex-fu used
for migration was a bit more involved in its own unique way (as every
one of these is) so here it is. Use it in conjunction with the apply.sh
script and associated find/xargs commands I've provided in rr230786 to
migrate your out of tree tests. Do let me know if any of this doesn't
cover your cases &amp; we can iterate on a more general script/regexes to
help others with out of tree tests.

About 9 test cases couldn't be automatically migrated - half of those
were functions returning function pointers, where I just had to manually
delete the function argument types now that we didn't need an explicit
function type there. The other half were typedefs of function types used
in calls - just had to manually drop the * from those.

import fileinput
import sys
import re

pat = re.compile(r'((?:=|:|^|\s)call\s(?:[^@]*?))(\s*$|\s*(?:(?:\[\[[a-zA-Z0-9_]+\]\]|[@%](?:(")?[\\\?@a-zA-Z0-9_.]*?(?(3)"|)|{{.*}}))(?:\(|$)|undef|inttoptr|bitcast|null|asm).*$)')
addrspace_end = re.compile(r"addrspace\(\d+\)\s*\*$")
func_end = re.compile("(?:void.*|\)\s*)\*$")

def conv(match, line):
  if not match or re.search(addrspace_end, match.group(1)) or not re.search(func_end, match.group(1)):
    return line
  return line[:match.start()] + match.group(1)[:match.group(1).rfind('*')].rstrip() + match.group(2) + line[match.end():]

for line in sys.stdin:
  sys.stdout.write(conv(re.search(pat, line), line))

llvm-svn: 235145
</pre>
</div>
</content>
</entry>
<entry>
<title>Use the generic Lfunc_begin label on ppc.</title>
<updated>2015-03-05T18:55:50+00:00</updated>
<author>
<name>Rafael Espindola</name>
<email>rafael.espindola@gmail.com</email>
</author>
<published>2015-03-05T18:55:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=86bd6a120232787e0a3e144aa8be62267f45c531'/>
<id>86bd6a120232787e0a3e144aa8be62267f45c531</id>
<content type='text'>
This removes yet another custom label to mark the start of a function.

llvm-svn: 231390
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This removes yet another custom label to mark the start of a function.

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