<html><body><p><tt><font size="2">"Reid Kleckner" <rnk@google.com> wrote on 29.09.2021 20:35:09:<br><br>> I don't think it would be reasonable for the SystemZ backend to <br>> abort every time it is asked to code generate an i32 argument that <br>> lacks an attribute. There are simply too many IR producers <br>> (frontends and instrumentation tools) that will pass unannotated i32<br>> values to calls. It's not feasible to fix them all, and aborting <br>> just means these producers will have to be updated whenever they are<br>> ported to SystemZ or any other target adopting the same practice.</font></tt><br><tt><font size="2">> <br>> I think it would instead be reasonable to pick a safer default for <br>> the target, like always zero extending unannotated parameters on <br>> both the caller side and the callee side. This is less efficient <br>> than only extending once in the caller, but it makes it much easier <br>> to retarget an IR producer over to SystemZ. It makes the attributes <br>> into performance improvements, not correctness requirements. I <br>> suspect this will not actually break passing a 4 byte struct, it <br>> just makes it less efficient.</font></tt><br><br><tt><font size="2">Unfortunately there is no "safe" default. If the callee expects</font></tt><br><tt><font size="2">a signed value, the argument has to be sign-extended; if the</font></tt><br><tt><font size="2">callee expects an unsigned value, the argument has to be zero-</font></tt><br><tt><font size="2">extended. Using the wrong extension is just as much a codegen</font></tt><br><tt><font size="2">bug as not extending at all.</font></tt><br><br><tt><font size="2">E.g. if the callee expects an "int" argument in a register,</font></tt><br><tt><font size="2">which is then used as index in a (64-bit) address, generated</font></tt><br><tt><font size="2">code may use that register without explicit extension, assuming</font></tt><br><tt><font size="2">the caller already sign-extended the value. If the caller</font></tt><br><tt><font size="2">passes -1, and wrongly zero-extends instead of sign-extending,</font></tt><br><tt><font size="2">the resulting address will be wrong.</font></tt><br><br><tt><font size="2">> As for the suggestion to add an explicit structarg attribute, can <br>> this be generalized to an attribute that marks the high bits as <br>> undef? So, IR producers will have a portable way to explicitly <br>> request the current behavior. This is kind of like `anyext`, but not<br>> really, more like `undefext`, `uext`, `hiundef` or `calleemustextend`.</font></tt><br><br><tt><font size="2">Agreed, this would be more general.</font></tt><br><br><tt><font size="2">Bye,</font></tt><br><tt><font size="2">Ulrich</font></tt><br><BR>
<BR>
</body></html>