If we inferred a range for the function return value, we can add !range
at all call-sites of the function, if the range does not include undef.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
llvm/test/Transforms/SCCP/ip-add-range-to-call.ll | ||
---|---|---|
28 | What does it mean to say the range doesn't "include undef", here? If the argument is poison, does this introduce UB? |
llvm/test/Transforms/SCCP/ip-add-range-to-call.ll | ||
---|---|---|
28 |
It is meant to refer to the 'range including undef' notion in ValueLattice. So it means that we know the result value cannot be undef, because all values merged with the return value state are known to not be undef. Reading it back it seems on its own it is not entirely clear. Please let me know if that makes sense, then I'll update the comment.
Hm, thinking a bit more about it, I guess it could. So for this example function, if %x would be poison, the result of the AND would also be poison, but we would add the range metadata nonetheless. It seems like the fact that returning values outside of !range is immediate UB makes it quite tricky to synthesize !range in the presence of of poison generally. I suppose we have 2 options here:
Doing 1. in the patch should be fairly straight forward, but 2. might be more beneficial in the long term. What do you think? |
llvm/test/Transforms/SCCP/ip-add-range-to-call.ll | ||
---|---|---|
28 |
This is the direction things are moving for call attributes, though I don't think any patches are up yet. Things like nonnull will only yield poison, and immediate UB will be introduced (if desired) by the noundef attribute. Keeping that in mind, it would make sense if !range and !nonnull followed the same behavior. |
llvm/test/Transforms/SCCP/ip-add-range-to-call.ll | ||
---|---|---|
28 |
Hm, having direct UB seems more convenient for the consumers of the metadata, as it rules out the result being poison/undef, allowing the information to be used directly. If we relax it to poison, things might get more difficult for consumers. But then, for callsites there's the noundef attribute to restore old behavior. That leaves loads, for which there would be no way to restore immediate UB I think. |
clang-tidy: warning: 'auto &CR' can be declared as 'const auto &CR' [llvm-qualified-auto]
not useful