<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 15, 2020 at 5:46 PM Manuel Jacob via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A function declaration declares a function pointer to the memory where <br>
the machine code will be at runtime. Besides providing the ability to <br>
call the function, that pointer can also be used, after bitcasting it, <br>
to modify the machine code implementing the function. What does the <br>
optimizer assume about the memory containing the machine code?<br>
<br>
The following is an example where Alive2 assumes that transforming @src <br>
to @tgt is correct (note that @f is marked readnone):<br>
<br>
<br>
declare i32 @f() readnone<br>
declare void @modify_f()<br>
<br>
define i32 @src() {<br>
   call void @modify_f()<br>
   %r = call i32 @f()<br>
   ret i32 %r<br>
}<br>
<br>
define i32 @tgt() {<br>
   %r = call i32 @f()<br>
   call void @modify_f()<br>
   ret i32 %r<br>
}<br>
<br>
<br>
Is this actually a correct transformation?<br>
<br>
If yes, what is the exact rule?<br>
<br>
Several possibilities come to my mind:<br>
<br>
* The memory at @f is assumed to be constant. If this is the case, how <br>
can it be communicated to the optimizer that the memory is modified?<br>
* In the following part of the definition of the "readnone" attribute, <br>
"memory" includes the machine code of the callee: "On a function, this <br>
attribute indicates that the function computes its result (or decides to <br>
unwind an exception) based strictly on its arguments, without <br>
dereferencing any pointer arguments or otherwise accessing any mutable <br>
state (e.g. memory, control registers, etc) visible to caller <br>
functions.". However, then the following part would be inconsistent (if <br>
executing machine code is considered reading): "If a readnone function <br>
reads or writes memory visible to the program, or has other <br>
side-effects, the behavior is undefined.".<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>