<div dir="ltr"><div dir="ltr">On Mon, 29 Nov 2021 at 12:50, Sankisa, Krishna (Chaitanya) via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<p style="font-family:Arial;font-size:10pt;color:rgb(0,0,255);margin:5pt" align="Left"><span style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif">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 ).</span><br></p></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
When reinterpretation of bits is not supported by target, the resultant value is poison.</div></div></div></blockquote><div><br></div><div>This will depend on the target's own interpretation of what each address space is meant to be.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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`.</div><div><br></div><div>Makes sense?</div><div><br></div><div>cheers,</div><div>--renato</div><div><br></div><div>[1] <a href="https://www.kernel.org/doc/html/latest/x86/x86_64/fsgs.html">https://www.kernel.org/doc/html/latest/x86/x86_64/fsgs.html</a></div></div></div>