[llvm-commits] [llvm-gcc-4.2] r55796 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
Chris Lattner
clattner at apple.com
Sun Sep 21 15:51:43 PDT 2008
On Sep 9, 2008, at 1:07 AM, Duncan Sands wrote:
>>> Hi Dale, thinking about this more, I started wondering
>>> why you want to produce llvm.pow and friends at all.
>>> Does it actually bring any advantage?
>>
>> Functionally, no, the point is to get C semantics out of the
>> optimizers.
>
> Well, given that you have several versions of each routine
> (eg: pow that writes errno, pow that does not write errno
> but uses the rounding mode, pow that does not write errno
> and does not use the rounding mode), that makes for a lot
> of intrinsics! Don't forget that SimplifyLibcalls performs
> simplifications that apply to all those different pow variants.
If anyone cared enough, this could be modeled by adding additional i1
arguments to llvm.pow. There is no need to make multiple different
intrinsics.
> That said, I think it is useful to distinguish between
> SimplifyLibcalls (SLC) and the rest of the compiler.
Yes, SLC is specific to code that is using the standard C library. If
you were writing a compiler for some language which had 'sin' mean
something unusual, you'd just not run it.
> The SLC pass is special in that it only exists to muck
> around with the standard system library, so it's not
> unreasonable that it recognizes standard library functions.
> It can always be turned off (llvm-gcc has logic for that).
Yes, however, this also isn't sufficient. GCC has options like -fno-
builtin-sin or something like that (which disable individual builtins).
There are a couple of ways to handle this. One way to handle this is
to completely disable simplifylibcalls (and friends) when any builtin
is disabled. Another is to add an intrinsic for every standard C
function we care about (not very attractive, but possible) and have
the front-end do the lowering of call to intrinsic. A third approach
would be to add a note attribute to functions that are disabled, e.g.
a "not a builtin function" attribute or something like that.
> So, excluding SLC, what about the rest of the compiler?
>
> Well, ConstantFolding.cpp will constant fold a range of
> libcalls too. That's not so great - something should be
> done about this (not sure what). Probably llvm-gcc's
> logic should turn this off too, but it currently doesn't...
Yes, this would require solution #2 or #3 if anyone cared enough.
> The other place is codegen:
> SelectionDAGBuild.cpp turns several things into SDNodes:
> not just pow and cos intrinsics but also functions called
> "cos". Two comments about this: (1) it implies that the
> llvm intrinsics must be readnone and not readonly; (2) I
> think the recognizing of names like "sin" should be dropped
> and only intrinsics used here (this is maybe what you had in
> mind). Let me explain (1): why an SDNode shouldn't be generated
> unless the function is readnone. Consider the following
> program:
There are really two issues w.r.t. rounding mode.
1) we don't model it at all in the IR. Theoretically, we'd like to
support the C99 pragmas, avoid moving FP operations (like adds) across
rounding mode changes, etc.
2) in the absence of proper modeling, we aren't always conservative
about our handling. For example, you're example of moving a cos
across a rounding mode change. However, we already move add/sub/mul/
div across rounding mode changes, so I'm not sure how cos is that
different.
-Chris
More information about the llvm-commits
mailing list