On Thu, May 3, 2018 at 11:29 PM, Jim Wilson <j...@sifive.com> wrote: > On Thu, May 3, 2018 at 12:29 AM, Richard Biener > <richard.guent...@gmail.com> wrote: >> Just as a note, IIRC all the SUBREG_PROMOTED_* stuff is quite fragile >> - I remember >> Eric fixing things up a bit but some verification would be nice to >> have (instrumentation >> at RTL level that for SUBREG_PROMOTED_* the bits are as expected). > > If you are using SUBREG_PROMOTED_* in a late optimization pass like > combine, then this requires that all earlier optimization passes > propagate the info correctly. I suppose there could be issues there. > But that isn't what this patch is doing. This is code called during > initial RTL generation. The SUBREG_PROMOTED_* bits are set during > this process because we know that arguments are passed sign-extended > to full register size. We are then consuming the info while still in > the RTL generation phase. I think that there is little that can go > wrong here.
Indeed. But IIRC the info stays around and people might be tempted to use it... I do see various uses in later RTL optimizers. > Verifying this info in RTL generation would effectively be verifying > that the argument passing conventions are implemented correctly, and > we already have other ways to do that. > > It might be useful to try to verify this info before combine where it > is more likely to be wrong. I don't think there is any easy way to > verify this at compile time. This would probably require emitting > code to check at application run-time that a promoted subreg actually > has a properly promoted value, and call abort if it doesn't. This > would likely be an expensive check that we don't want enabled by > default, but might be useful for debugging purposes. I don't think we > have any --enable-checking code like this at present. We have > compiler compile-time checking and compiler run-time checking, but I > don't think that we have application run-time checking. This would be > more like a sanitizer option, except to validate info in the RTL. Is > this what you are asking for? Yes, that's what I was suggesting. I guess similarly "sanitizing" on-the-side info we have at GIMPLE level would be interesting, like verifying range-info. Just an idea - I'm not actually expecting you to implemen this, esp. since doing the actual instrumentation on RTL can be a bit tricky (best not emit a call to abort but use the targets trap instruction for simplicity). Richard. > > Jim
