<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 1/24/14 3:52 PM, Raul Silvera wrote:<br>
</div>
<blockquote
cite="mid:CA+PGoB8mCLRwM-xo=WUHA1RPYjMgg=6YYeHtiUH=3F=RM8njaw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif">In
include/llvm/IR/Intrinsics.td there is code to mark sqrt and
several other math intrinsics as "ReadOnly", even though they
do not read memory.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">According to the
comments this was done as an attempt to model changes to the
FP rounding mode. This is too conservative, and unnecessarily
blocks transformations such as commoning and vectorization.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">I have heard from
others that FP environment changes are not well modeled on
LLVM anyway, so perhaps it is appropriate to just change these
from ReadOnly to ReadNone. Any opinions on this? If there are
no objections I'll prepare a patch.</div>
</div>
</blockquote>
While our current modeling isn't quite right (e.g. we don't model
writes to errno and related state), I'm very reluctant to see us
move in the direction you propose. I'm leary of having intrinsics
which are modeled incorrectly and relying on the optimizers not to
exploit that fact and yield incorrect code. This seems like a
recipe for disaster long term. <br>
<blockquote
cite="mid:CA+PGoB8mCLRwM-xo=WUHA1RPYjMgg=6YYeHtiUH=3F=RM8njaw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">The alternative would
be to develop a mechanism to finely model FP environment
changes; even further, it might be possible to come up with a
unified model of library call side effects, including errno
and even I/O.</div>
</div>
</blockquote>
I know there had been some work discussed on list around modelling
errno explicitly. I'm not sure what happened with that or what the
current status is.<br>
<br>
I would be mildly supportive of an effort to add optional explicit
alias sets to function declarations. I have an (out-of-tree)
use-case which might benefit from such as well. <br>
<br>
Philip<br>
</body>
</html>