[llvm-commits] [llvm-gcc-4.2] r55796 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

[Duncan Sands]

Hi,

> This doesn't do the right thing for Darwin, and is inconsistent with  
> the existing handling of sqrt, which is explicitly tested in the  
> testsuite.

what does it do wrong on Darwin?  And it is not inconsistent with
the handling of sqrt, because the gcc sqrt builtin should be
readnone if and only if it doesn't set errno (ok, maybe it will
be readonly if it doesn't set errno - depends on the platform).

> The difficulty does seem to be the rounding mode.  I don't agree that  
> reading the rounding mode should prevent marking things "readnone";
> the description can be read that way, but it's pretty clear whoever  
> wrote it wasn't thinking of rounding mode.

I had rounding mode in mind when I added all this stuff.
The gcc people set math functions as pure (readonly)
rather than const (readnone) exactly because of the
rounding mode, except for some platforms (Darwin)
and with some options (fast-math).

> Rounding mode is not memory.

Suppose I call pow, then I change the rounding mode, then call
pow again.  The result the second time may well be different.
But if pow is readnone then GVN and other passes will think
the result is the same and only call pow once.  This is just
wrong.

> There is no reason a libcall that reads rounding mode, but  
> doesn't touch memory, can't be moved across loads and stores.

A readnone function can be moved across anything, including
calls to the function setting rounding mode!

> (It can't be moved across instructions that change the rounding mode, but  
> we don't currently model that, and this consideration is orthogonal to  
> touching memory.)

The rounding mode can be considered a memory location, it's just
that it's kept inside the processor rather than in main memory.

Ciao,

Duncan.