[llvm-dev] What can the optimizer assume about the memory a global function pointer points to?

[Johannes Doerfert via llvm-dev]

Hi Manuel,


So I haven't thought about this much but here some initial reactions:


I guess if you want to modify the code of a definition you need to mark 
it as `naked` or similar. We analyze the code after all, if it changes 
whatever we derived is pretty much wrong. However, you could also not 
reliably change the code if we can modify it so to make changes "sane" 
you need `naked` anyway.


I don't think the declaration should not be `__attribute__((pure))` ~ 
`readnone` if its code, can change. One could argue similar to the above 
case, e.g., it needs to be `naked` and therefore cannot be `readnone` 
(not that we have the restriction). Or one could say you break the 
implicit property of `pure`/`readnone` that is used all over the place: 
No matter when or where it is called the result is the same.


I agree that the LangRef is pretty light on this topic.


Cheers,

   Johannes


On 4/16/20 1:46 PM, Manuel Jacob via llvm-dev wrote:
> On 2020-04-16 18:26, Hiroshi Yamauchi wrote:
>> I am not sure if the IR spec that explicitly talks about this, but I'm
>> under the impression that the code memory is assumed to be constant or
>> abstracted out at the IR level and the IR optimizer does not need to 
>> think
>> about the code getting modified or just treats it as undefined behavior.
>
> One case where the Language Reference explicitly mentions the 
> possibility of modifying machine code is Prologue Data: 
> http://llvm.org/docs/LangRef.html#prologue-data
>
> So at least the prologue part is seemingly not considered constant. 
> The question of what ordering restrictions are placed between calls 
> and code potentially modifying the callee machine code is still 
> unclear, though.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200416/b83b663b/attachment.html>