I don't really know if this is useful or not, i was just curious to try to make something like this.
There may be several use-cases:
- Verify that front-end indeed did mark every instruction that could have such a TBAA Access Tag (TBAAVerifier::CouldHaveTBAAAccessTag()) with the tag.
- Assuming that the input is ok (see previous point), verify that the passes don't loose these tags, don't.
The design is very simplistic right now:
- One option to toggle the check (default to off)
- One option on how to treat the missing access tag:
- Treat any missing tag as a fatal error
- Missing tag is never a error
- If there is at least one instruction that is tagged, then a missing tag is an error.
The last option makes sense to be the default, e.g. because one can globally disable TBAA info
(-O0, -fno-strict-aliasing?), and then *nothing* is tagged. Since we can't know beforehand
if there is a TBAA metadata, i simply track whether we have seen any tagged instructions,
and decide whether this is a fatal error at the end.
An observation: while trying to test, i have *quickly* found this very simple test,
,in which the loads/stores aren't being tagged (with roughly -O1 -fstrict-aliasing + verifier enabled).
I'm sure there are more.
Now, question[s]:
- If TBAA is enabled, are there valid (i.e. not a bug) cases where these missing tags are genuinely ok/intentional? That would make this way less useful.
- Does this have any actual use cases? (no is an ok answer, too)
- Should i try to look into this further, look into missing tags?
We generate a significant amount of such instructions that are not supposed to be decorated. See for example D41562 and D39138. For my local experiments I was adding marks associated with load and store instructions that give a clue on their origin. If we can have such a mechanism in the mainline to make things like this patch more useful, then that would be great.