[PATCH] D28335: [WIP] [RFC] Don't lower floating point intrinsics to libcalls which modify errno

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D28335#636356, @efriedma wrote:

> > We also do need to model errno, however, or provide compiler-rt wrappers,etc. so that we can really use -fno-math-errno on systems where the math functions really do set errno and not miscompile code by reordering calls to math functions with calls to other functions (e.g. open, read) that set errno and where errno is later used (e.g. by perror).
>
> Yes, that's what I was getting at with "Fix clang so it doesn't mark calls which have side-effects readnone."  It's hard to come up with a good solution here, though.  The options I can think of:
>
> 1. Make compiler-rt implement a bunch of libm functions with sane semantics.  Straightforward, but writing fast, correct libm routines is tricky.


No, you just need to wrap them such that you save/restore errno around the calls to the libm implementation.

> 2. Instead of marking the math functions readnone, mark them "dead_errno_write" or something like that.  That allows correct modeling, but it probably ends up blocking a substantial number of optimizations because we have to assume almost any pointer could alias errno.
> 3. Some solution which involves teaching the compiler or compiler-rt how to compute the address of errno.  This gets nasty fast because it's different for every libc implementation.

I know. I posted an RFC at some point where I detailed how errno is implemented across a wide range of implementations. It is nasty, at least in theory, but practically, it is not as bad as you might fear.

> That's largely orthogonal to this patch, though.

It is in some sense, but understanding how we want to proceed here is an important part of this overall space, and directly affects whether it is reasonable to assume that the intrinsics will have no side effects.


Repository:
  rL LLVM

https://reviews.llvm.org/D28335