[llvm-dev] New intrinsic property IntrOnlyWrite

Matthias Braun via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 21 21:25:47 PDT 2016


> On Mar 21, 2016, at 9:14 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
>> On Mar 21, 2016, at 8:58 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> 
>> On 19.03.2016 16:25, Mehdi Amini wrote:
>>> Hi,
>>> 
>>> Can you elaborate what is the impact at the IR level?
>>> If the point is just about how you lower for you target, why are you needing an IR level attribute? You backend if free to specialize the lowering for any intrinsic regardless the IR level attributes.
>> 
>> As I explained in my reply to Philip, what I really need is a way to get TableGen to shut up about what it reasonably believes to be a mismatch between the properties of the intrinsic (which it conservatively believes to be mayLoad = 1, mayStore = 1, hasSideEffects = 1) and the hardware instruction (which is correctly mayLoad = 0, mayStore = 1, hasSideEffects = 0).
> 
> I'm not sure what is the semantics of "hasSideEffects" at the MI level. I'm surprised we can consider correct that something that writes to memory is not "having side effects".
> 
> At the IR level, the definition of "mayHaveSideEffects" is more coherent with what I expect:
> 
>  bool mayHaveSideEffects() const {
>    return mayWriteToMemory() || mayThrow() || !mayReturn();
>  }
> 
>> Indeed, write-only without an ArgMemOnly property may well be useless at the IR level. If you think that there is a better way to explain the situation to TableGen, please let me know.
> 
> I don't really understand why an MI which is "mayLoad" would have a side effect?
> I don't get either why not an MI which is "mayStore" would not have a side effect. I'd expect that mayStore imply "hasSideEffect" (i.e. the latter being a strict superset). 
> (but hey, I'm not an MI expert and I'd need some clarification on the implication of "hasSideEffect" at the MI level)
The MI level talks about side effects not modeled by any other mechanism (MCInstrDesc::hasUnmodeledSideEffects()) which is more useful than a conservative as we can differentiate between effects of memory read/writes (to possible known addresses) and arbitrary things (like wait for input, write to device, ...).

- Matthias


More information about the llvm-dev mailing list