On Nov 12, 2009, at 11:29 PM, John McCall wrote:>> sext/zext/trunc are very nice for the optimizer, we should keep >> them. It means that the optimizer doesn't have to check that the >> input to a sext is bigger or smaller than the result, for example. >> Code that cares (e.g. instcombine) really likes this. > > We could just say that code has undefined behavior or is invalid if > the 'sext', 'zext', or 'trunc' is inappropriate for the actual size > of intptr. I think this is reasonable; if the frontend emits a > zext intptr to i32, and the pointer side is i64, that *should* be > invalid. This way the optimizer gets to keep its assumptions and it > becomes the client's responsibility to ensure that its "target- > neutral" bitcode really is neutral for the range of platforms it > actually cares about. Portable code can't be truncating arbitrary > pointers to some smaller type anyway; if the client just wants to > munge the bottom bits, it can zext and trunc to and from i8/i12/ > whatever.The optimizer assumes that the input and output of (e.g.) zext are both IntegerType's (which intptr won't be) and that the input is smaller (and thus non-equal to) the result type. We really don't want to break these invariants, -Chris
Chris Lattner wrote:> On Nov 12, 2009, at 11:29 PM, John McCall wrote: >>> sext/zext/trunc are very nice for the optimizer, we should keep >>> them. It means that the optimizer doesn't have to check that the >>> input to a sext is bigger or smaller than the result, for example. >>> Code that cares (e.g. instcombine) really likes this. >> >> We could just say that code has undefined behavior or is invalid if >> the 'sext', 'zext', or 'trunc' is inappropriate for the actual size >> of intptr. I think this is reasonable; if the frontend emits a zext >> intptr to i32, and the pointer side is i64, that *should* be >> invalid. This way the optimizer gets to keep its assumptions and it >> becomes the client's responsibility to ensure that its >> "target-neutral" bitcode really is neutral for the range of platforms >> it actually cares about. Portable code can't be truncating arbitrary >> pointers to some smaller type anyway; if the client just wants to >> munge the bottom bits, it can zext and trunc to and from >> i8/i12/whatever. > > The optimizer assumes that the input and output of (e.g.) zext are > both IntegerType's (which intptr won't be) and that the input is > smaller (and thus non-equal to) the result type. We really don't want > to break these invariants,I didn't realize that an identity zext was actually invalid IR. That seems like it probably causes more trouble than it's worth. Anyway, I suspect the question is whether you would rather break these invariants (which are probably not critical for most optimizations) or slowly accumulate duplicate code paths in every pass that looks at zexts and truncs. John.
John McCall wrote:> I didn't realize that an identity zext was actually invalid IR. That > seems like it probably causes more trouble than it's worth. > > Anyway, I suspect the question is whether you would rather break these > invariants (which are probably not critical for most optimizations) or > slowly accumulate duplicate code paths in every pass that looks at zexts > and truncs. >Actually, I take this back; there are definitely common optimizations that are going to be much more complicated if they have to deal with intptrs, most obviously instcombining trunc/zext/sext. John.