[llvm-dev] [RFC] : LLVM IR should allow bitcast between address spaces with the same size

[Renato Golin via llvm-dev]

On Mon, 29 Nov 2021 at 12:50, Sankisa, Krishna (Chaitanya) via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> This bitcast is intended to be used by transform passes when its been
> decided that the resultant operation is no-op( Like in GVN case of
> inserting ptrtoint/inttoptr ).
>
When reinterpretation of bits is not supported by target, the resultant
> value is poison.
>

This will depend on the target's own interpretation of what each address
space is meant to be.

Each optimisation that uses this will have to ask the target info classes
for the similarity (for some definition of) between two address spaces and
then checking if the cast is actually a no-op or not.

As Serge said, some targets use address spaces for things that are
completely segregated even if they have the same data layout (ex. [1]).
Bit-casting on those cases is an invalid operation.

As a result, the infrastructure that allows this must be extremely
conservative (ie. return false on the base class) and only return true
after enough checks are done by the target library, and then it's up to
that target to allow/deny bit-casts between address spaces (which at that
point, don't even need to have the same data layout).

In a nutshell, I don't think *only* looking at the data layout will be
safe. You need to dig deeper and make that a target decision, and allow
passes to completely ignore this specific pattern (ie. avoid searching the
whole IR for it) if there's no chance it will ever be useful. This makes
sure targets that don't support that don't pay the penalty of traversing
the IR for no benefit, because the response will always be `false`.

Makes sense?

cheers,
--renato

[1] https://www.kernel.org/doc/html/latest/x86/x86_64/fsgs.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211129/69bff16c/attachment.html>