Try to turn calls that look like operators into known
intrinsics. Also try to turn calls that look like a load or
a store into a load or store.
Details
- Reviewers
aeubanks regehr lebedev.ri
Diff Detail
Event Timeline
llvm/tools/llvm-reduce/deltas/ReduceOpcodes.cpp | ||
---|---|---|
98–101 | Could invert this to reduce indentation? if (!IsStore || DataArg) return false; DataArg = Arg; (or even split out the two conditions and have separate returns - keep each one simpler) | |
183 | This amounts to an else-after-return, since the above switch is exhaustive - maybe skip the else? (& tag the end of the previous if with llvm_unreachable - same thing with this following if. |
llvm/tools/llvm-reduce/deltas/ReduceOpcodes.cpp | ||
---|---|---|
139 | volatile acts more like a call with a pointer. It's treated as a pointer capture, has stricter scheduling. Plus we may be emitting a load/store from null in the default address space, so this makes that defined. If the volatile doesn't matter, the volatile reduction can remove it later | |
194 | An intrinsic has known behavior, an arbitrary external call doesn't. From a semantics perspective, that's more understandable |
llvm/tools/llvm-reduce/deltas/ReduceOpcodes.cpp | ||
---|---|---|
194 | from a "I want to submit this IR reproducer as a test case" standpoint, calling an intrinsic as opposed to an arbitrary call is weirder. there's very little code that deals specifically with fshl at least in the middle-end, but a lot that deals with generic calls. so picking some random intrinsic is weird but sure, we can go with this and see if people (I) get annoyed or not |
Could invert this to reduce indentation?
(or even split out the two conditions and have separate returns - keep each one simpler)