> I have set out here to just fix the problem at hand, but it is a bit > worrying that cse is about to replace a read with a copy of a value read > before using an alias set that is not considered compatible. > It would be OK if the alias set of the re-used read was adjusted, but I > don't think we have any such code in cse.
I don't think that's a problem, as the second read must be done with an appropriate type in order to be valid if there is no intervening write. > In this case, avoiding an invalid transformation (due to anti-dependency) > avoids further complications from the alias sets, but what if we had > a more complex case? Could we end up with a non-matching write/read pair > that can be re-ordered by subsequent passes? It couldn't be for sharing > a previous stack-slot like in the test cases here, since then we would > have to have an uninitialized read or overlapping lifetimes to start with, > but maybe it could happen when using union member/aliased read accesses > with use that depends on a discriminator? I'd think that the latest RTL aliasing model is conservative enough as to be safe (modulo bugs) but these are IMO legitimate questions whose answer is not immediate, so it would be nice to have a summary written down somewhere, and that would probably be at the beginning of alias.c. Michael, would you mind writing down one as a follow-up to the stack slot sharing patch when you have some time? The patch effectively breaks long-held assumptions in RTL alias analysis, so that would really help. TIA. > Now, if we had an rtl interpreter that can be invoked in addition to/instead > of a dump generation with specific options, and this interpreter not only > kept track of values being initialized (as valgrind does), but actually > kept track of the alias of the last write for each addressable unit, and > checked the compatibility of the alias set on read, we'd have a powerful > tool to both add new regression tests, and to help during debugging where > the compiler goes wrong, or for a user, to check if his/her code contains > alias set problems. > Would this be suitable for a GSOC project? I don't know, that seems to be a bit daunting for a GSOC project. -- Eric Botcazou
