[llvm-dev] [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?

Tue Jan 9 13:19:22 PST 2018

> If the pragma applies to the entire function then would it be as simple as a pass to
> convert intrinsic calls into whatstheterm SNodes (?) after the optimization passes
> have run? Meaning, we can bypass any changes to the AST?

The pragma doesn't necessarily apply to the entire function. As I said, the language standard says that the pragma applies at a scope level. The thing that applies to the entire function (and this is an implementation choice) is whether or not we're going to required constrained intrinsics to be used.

The intrinsics do get converted to selection DAG nodes after the optimization passes have been run. This is a separate issue from the AST. I think that's about controlling where the FP constraints need to be applied. As I said, that's beyond my skill set so I should stop talking now.

> BTW, I thought that optimization passes were allowed to drop metadata.
> So what happens to the metadata on the constrained intrinsic calls? Or am
> I mixing up two different metadatas?

The metadata in this case is a little special because it's being used as an argument to a function call. That won't ever be dropped.

> How would you prevent [constant folding in machine IR]?

To be honest, I don't know. I don't think there is an existing mechanism to prevent it. Given that no one has thought it was important to be able to do this kind of optimization in Machine IR, maybe it would be best just to state it as a rule that it isn't allowed. As far as I can tell, this is all that prevents fast-math kinds of operations, so maybe it is sufficient here too.

The trapping considerations are really more significant in that there are other optimizations we want to be able to perform that can violate our exception safety expectations. We need to be able to allow those kinds of optimizations by default but prevent them when strict FP semantics are needed. Constant folding, on the other hand, doesn't appear to be critical to performance at the MIR level.

-Andy

-----Original Message-----
From: Kevin P. Neal [mailto:kpn at neutralgood.org] 
Sent: Tuesday, January 09, 2018 11:37 AM
To: cfe-dev at lists.llvm.org
Cc: Kaylor, Andrew <andrew.kaylor at intel.com>; Ulrich Weigand <Ulrich.Weigand at de.ibm.com>; bumblebritches57 at gmail.com; bob.huemmer at sas.com; llvm-dev <llvm-dev at lists.llvm.org>; Richard Smith <richard at metafoo.co.uk>
Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?

On Tue, Jan 09, 2018 at 06:53:51PM +0000, Kaylor, Andrew via cfe-dev wrote:
>    I think we're going to need to create a new mechanism to communicate
>    strict FP modes to the backend. I think we need to avoid doing anything
>    that will require re-inventing or duplicating all of the pattern
>    matching that goes on in instruction selection (which is the reason
>    we're currently dropping that information). I'm out of my depth on this
>    transition, but I think maybe we could handle it with some kind of
>    attribute on the MBB.
> 
> 
>    In C/C++, at least, it's my understanding that the pragmas always apply
>    at the scope-level (as opposed to having the possibility of being
>    instruction-specific), and we've previously agreed that our
>    implementation will really need to apply the rules across entire
>    functions in the sense that if any part of a function uses the
>    constrained intrinsics all FP operations in the function will need to
>    use them (though different metadata arguments may be used in different
>    scopes). So I think that opens our options a bit.

If the pragma applies to the entire function then would it be as simple as a pass to convert intrinsic calls into whatstheterm SNodes (?) after the optimization passes have run? Meaning, we can bypass any changes to the AST?

That would still leave the backend changes to be done, of course.

BTW, I thought that optimization passes were allowed to drop metadata. So what happens to the metadata on the constrained intrinsic calls? Or am I mixing up two different metadatas?

>    Regarding constant folding, I think you are correct that it isn't
>    happening anywhere in the backends at the moment. There is some
>    constant folding done during instruction selection, but the existing
>    mechanism prevents that. My concern is that given LLVM's development
>    model, if there is nothing in place to prevent constant folding and no
>    consensus that it shouldn't be allowed then we should probably believe
>    that someone will eventually do it.

How would you prevent it?

>    -Andy
> 
> 
>    From: Ulrich Weigand [mailto:Ulrich.Weigand at de.ibm.com]
>    Sent: Tuesday, January 09, 2018 9:59 AM
>    To: Kaylor, Andrew <andrew.kaylor at intel.com>; kpn at neutralgood.org
>    Cc: Hal Finkel <hfinkel at anl.gov>; Richard Smith
>    <richard at metafoo.co.uk>; bob.huemmer at sas.com;
>    bumblebritches57 at gmail.com; wei.ding2 at amd.com; cfe-dev at lists.llvm.org;
>    llvm-dev <llvm-dev at lists.llvm.org>
>    Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
> 
> 
>    Andrew Kaylor wrote:
>    >In general, the current "strict FP" handling stops at instruction
>    >selection. At the MachineIR level we don't currently have a mechanism
>    >to prevent inappropriate optimizations based on floating point
>    >constraints, or indeed to convey such constraints to the backend.
>    >Implicit register use modeling may provide some restriction on some
>    >architectures, but this is definitely lacking for X86 targets. On the
>    >other hand, I'm not aware of any specific current problems, so in many
>    >cases we may "get lucky" and have the correct thing happen by chance.
>    >Obviously that's not a viable long term solution. I have a rough plan
>    >for adding improved register modeling to the X86 backend, which should
>    >take care of instruction scheduling issues, but we'd still need a
>    >mechanism to prevent constant folding optimizations and such.
>    Given that Kevin intends to target SystemZ, I'll be happy to work on
>    the SystemZ back-end support for this feature. I agree that we should
>    be using implicit control register dependencies, which will at least
>    prevent moving floating-point operations across instructions that e.g.
>    change rounding modes. However, the main property we need to model is
>    that floating-point operations may *trap*. I guess this can be done
>    using UnmodeledSideEffects, but I'm not quite clear on how to make this
>    dependent on whether or not a "strict" operation is requested (without
>    duplicating all the instruction patterns ...).
>    Once we do use something like UnmodeledSideEffects, I think MachineIR
>    passes should handle everything correctly; in the end, the requirements
>    are not really different from those of other trapping instructions.
>    B.t.w. I don't think anybody does constant folding on floating-point
>    constants at the MachineIR level anyway ... have you seen this
>    anywhere?
>    Mit freundlichen Gruessen / Best Regards
>    Ulrich Weigand
>    --
>    Dr. Ulrich Weigand | Phone: +49-7031/16-3727
>    STSM, GNU/Linux compilers and toolchain
>    IBM Deutschland Research & Development GmbH
>    Vorsitzende des Aufsichtsrats: Martina Koederitz | Gesch ftsf hrung:
>    Dirk Wittkopp
>    Sitz der Gesellschaft: B blingen | Registergericht: Amtsgericht
>    Stuttgart, HRB 243294

> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

"What is mathematics? The age-old answer is, of course, that mathematics  is what mathematicians do." - Donald Knuth