llvm dev - Sep 2013 - [LLVMdev] [RFC] New function attributes for errno-setting functions

----- Original Message -----
> On 9/12/2013 7:44 PM, Hal Finkel wrote:
> >
> > To fix this problem, I think that we need to stop treating errno as
> > some arbitrary external state, and model is explicitly.
> 
> In such case it would make sense to know when "errno" is read. 
This
> way
> we could detect whether it's actually used, whether or not the
> -fno-math-errno (or some generic -fno-xyz-errno) was specified.
>  Problem
> is that errno (referenced explicitly) may be a macro that expands to
> some system-specific function call.

I agree, and this is exactly the problem: It is really hard, as far as I
understand, to figure out what 'errno' actually is. On the other hand,
the frontend has more information on this, at least in theory, and maybe it
could communicate it to the backend somehow. Maybe the easiest way would be to
insert an intrinsic @llvm.errno.read() whenever errno (as a source token)
appears in the source as an rvalue (and do some similar thing when it appears as
a lvalue). Thoughts?
> 
> On that note, what would be really nice is if a function could have
> an
> "mod/use" sets attached to it, which would specify what external
> symbols
> this function can reference.  I'm not sure how that could be
> expressed
> in the current IR though.
We could attach this as metadata currently. In terms of extending the IR, we
might be able to add 'implicit' function parameters similar to what we
do for MIs.

 -Hal
> 
> -K
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On 9/13/2013 2:23 PM, Hal Finkel wrote:
>
> Maybe the easiest way would be to insert an intrinsic @llvm.errno.read()
whenever errno (as a source token) appears in the source as an rvalue (and do
some similar thing when it appears as a lvalue). Thoughts?
I think the major problem is still with "errno" defined as a 
preprocessor macro, as it may not look like errno by the time the 
front-end sees it.  Perhaps some configuration test could preprocess 
something like "var = errno;" and check what's really getting
stored in
"var", but it may be unreliable (i.e. not detect all cases).

I thought a bit more about it and I think we will need to have this 
information to prevent similar problems as the one you mentioned in the 
first post.  For example:

   int fd = open(...);
   int saved_errno = errno;
   double s = sqrt(var);
   if (fd == -1)
     fprintf(stderr, "error: %d\n", saved_errno);


With only the information about modifying errno, this code could be 
transformed to

   int fd = open(...);
   double s = sqrt(var);
   int saved_errno = errno;
   if (fd == -1)
     fprintf(stderr, "error: %d\n", saved_errno);

again producing the same situation.


-K


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

----- Original Message -----
> On 9/13/2013 2:23 PM, Hal Finkel wrote:
> >
> > Maybe the easiest way would be to insert an intrinsic
> > @llvm.errno.read() whenever errno (as a source token) appears in
> > the source as an rvalue (and do some similar thing when it appears
> > as a lvalue). Thoughts?
> 
> I think the major problem is still with "errno" defined as a
> preprocessor macro, as it may not look like errno by the time the
> front-end sees it. 
That's why I said source token (I meant preprocessor token), but any such
solution would not be robust to preprocessed source files, and that seems like a
big problem.
> Perhaps some configuration test could preprocess
> something like "var = errno;" and check what's really getting
stored
> in
> "var", but it may be unreliable (i.e. not detect all cases).
> 
> I thought a bit more about it and I think we will need to have this
> information to prevent similar problems as the one you mentioned in
> the
> first post.  For example:
> 
>    int fd = open(...);
>    int saved_errno = errno;
>    double s = sqrt(var);
>    if (fd == -1)
>      fprintf(stderr, "error: %d\n", saved_errno);
> 
> 
> With only the information about modifying errno, this code could be
> transformed to
> 
>    int fd = open(...);
>    double s = sqrt(var);
>    int saved_errno = errno;
>    if (fd == -1)
>      fprintf(stderr, "error: %d\n", saved_errno);
> 
> again producing the same situation.
No, I don't think so. If sqrt is not readnone or readonly, then it should
potentially alias whatever the errno macro actually expands to (whether it is a
global variable, and thread-local variable, a function call, or whatever).

 -Hal
> 
> 
> -K
> 
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory