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

> On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <cfe-dev at
lists.llvm.org> 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.
>  
> 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.
The standard argument against trying to introduce "scope-like"
mechanisms to LLVM IR is inlining; unless you're going to prevent functions
that use stricter/laxer FP rules from being inlined into each other (which
sounds disastrous), you're going to need to communicate strictness on an
instruction-by-instruction basis.  If the backend wants to handle that by using
the strictest rule that it sees in use anywhere in the function because
pattern-matching is otherwise too error-prone, ok, that's its right; but the
IR really should be per-instruction.

John.
>  
> -Andy
>   <>
> From: Ulrich Weigand [mailto:Ulrich.Weigand at de.ibm.com
<mailto:Ulrich.Weigand at de.ibm.com>]
> Sent: Tuesday, January 09, 2018 9:59 AM
> To: Kaylor, Andrew <andrew.kaylor at intel.com <mailto:andrew.kaylor
at intel.com>>; kpn at neutralgood.org <mailto:kpn at
neutralgood.org>
> Cc: Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at
anl.gov>>; Richard Smith <richard at metafoo.co.uk <mailto:richard
at metafoo.co.uk>>; bob.huemmer at sas.com <mailto:bob.huemmer at
sas.com>; bumblebritches57 at gmail.com <mailto:bumblebritches57 at
gmail.com>; wei.ding2 at amd.com <mailto:wei.ding2 at amd.com>; cfe-dev
at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>; llvm-dev
<llvm-dev at lists.llvm.org <mailto: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 <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180109/c885ca98/attachment.html>

>The standard argument against trying to introduce "scope-like"
mechanisms to LLVM IR is inlining;
>unless you're going to prevent functions that use stricter/laxer FP
rules from being inlined >into
>each other (which sounds disastrous), you're going to need to
communicate strictness on an
>instruction-by-instruction basis.  If the backend wants to handle that by
using the strictest
>rule that it sees in use anywhere in the function because pattern-matching
is otherwise too
>error-prone, ok, that's its right; but the IR really should be
per-instruction.
I added a function level attribute, strictfp, which is meant to help with this.
I don’t believe the inlining handling of the attribute is implemented yet, but
what I’m thinking is that we would never inline a function that had the strictfp
attribute and if we inlined a non-strictfp function into a strictfp function, we
would transform any FP operations into their constrained equivalents at that
time. In the short term, we’d probably just block both types of inlining.

It may sound disastrous, but I think there’s an understanding that using strict
FP semantics is going to significantly inhibit optimizations. In the short term,
that’s actually the purpose of the constrained intrinsics -- to disable all
optimizations until we can teach the optimizer to do things correctly. The plan
is that once this is all implemented to produce correct results, we’ll go back
and try to re-enable as many optimizations as possible, which may eventually
include doing something more intelligent with inlining.

With regard to your “instruction level” comments, my intention is that the use
of the intrinsics will impose the necessary restrictions at the instruction
level. Optimizations (other than inlining) should never need to check the
function level attribute. But if we mixed “raw” FP operations and constrained
intrinsics within a single function there would be no way to prevent motion of
the “raw” operations across the intrinsics.

The reason I brought up the scope level nature of the pragma was just to suggest
that it might be a property that we could take advantage of to handle the
transition from IR to MIR. I haven’t come up with a way to bake the strict FP
information into the instructions across the ISel boundary, but I think it might
be possible to temporarily add it to a block and then have an early machine code
pass that used this information in some way once the MIR was all in place. I’m
open to the possibility that that was a bad idea.

-Andy


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


On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <cfe-dev at
lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> 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.

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.

The standard argument against trying to introduce "scope-like"
mechanisms to LLVM IR is inlining; unless you're going to prevent functions
that use stricter/laxer FP rules from being inlined into each other (which
sounds disastrous), you're going to need to communicate strictness on an
instruction-by-instruction basis.  If the backend wants to handle that by using
the strictest rule that it sees in use anywhere in the function because
pattern-matching is otherwise too error-prone, ok, that's its right; but the
IR really should be per-instruction.

John.



-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<mailto:andrew.kaylor at
intel.com>>; kpn at neutralgood.org<mailto:kpn at neutralgood.org>
Cc: Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>>;
Richard Smith <richard at metafoo.co.uk<mailto:richard at
metafoo.co.uk>>; bob.huemmer at sas.com<mailto:bob.huemmer at
sas.com>; bumblebritches57 at gmail.com<mailto:bumblebritches57 at
gmail.com>; wei.ding2 at amd.com<mailto:wei.ding2 at amd.com>; cfe-dev
at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>; llvm-dev <llvm-dev
at lists.llvm.org<mailto: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<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180109/2981a544/attachment.html>

> On Jan 9, 2018, at 3:50 PM, Kaylor, Andrew <andrew.kaylor at
intel.com> wrote:
> 
> >The standard argument against trying to introduce
"scope-like" mechanisms to LLVM IR is inlining;
> >unless you're going to prevent functions that use stricter/laxer FP
rules from being inlined >into
> >each other (which sounds disastrous), you're going to need to
communicate strictness on an
> >instruction-by-instruction basis.  If the backend wants to handle that
by using the strictest
> >rule that it sees in use anywhere in the function because
pattern-matching is otherwise too
> >error-prone, ok, that's its right; but the IR really should be
per-instruction.
>  
> I added a function level attribute, strictfp, which is meant to help with
this. I don’t believe the inlining handling of the attribute is implemented yet,
but what I’m thinking is that we would never inline a function that had the
strictfp attribute and if we inlined a non-strictfp function into a strictfp
function, we would transform any FP operations into their constrained
equivalents at that time. In the short term, we’d probably just block both types
of inlining.
>  
> It may sound disastrous, but I think there’s an understanding that using
strict FP semantics is going to significantly inhibit optimizations. In the
short term, that’s actually the purpose of the constrained intrinsics -- to
disable all optimizations until we can teach the optimizer to do things
correctly. The plan is that once this is all implemented to produce correct
results, we’ll go back and try to re-enable as many optimizations as possible,
which may eventually include doing something more intelligent with inlining.
>  
> With regard to your “instruction level” comments, my intention is that the
use of the intrinsics will impose the necessary restrictions at the instruction
level. Optimizations (other than inlining) should never need to check the
function level attribute. But if we mixed “raw” FP operations and constrained
intrinsics within a single function there would be no way to prevent motion of
the “raw” operations across the intrinsics.
Is that a problem?  Semantics are guaranteed only for strictfp operations, i.e.
ones that use the intrinsics.  Raw operations can get reordered across
intrinsics and change semantics, but that seems allowable, right?

John.

>  
> The reason I brought up the scope level nature of the pragma was just to
suggest that it might be a property that we could take advantage of to handle
the transition from IR to MIR. I haven’t come up with a way to bake the strict
FP information into the instructions across the ISel boundary, but I think it
might be possible to temporarily add it to a block and then have an early
machine code pass that used this information in some way once the MIR was all in
place. I’m open to the possibility that that was a bad idea.
>  
> -Andy
>  
>   <>
> From: rjmccall at apple.com [mailto:rjmccall at apple.com] 
> Sent: Tuesday, January 09, 2018 11:12 AM
> To: Kaylor, Andrew <andrew.kaylor at intel.com>
> Cc: Ulrich Weigand <Ulrich.Weigand at de.ibm.com>; kpn at
neutralgood.org; bumblebritches57 at gmail.com; bob.huemmer at sas.com; llvm-dev
<llvm-dev at lists.llvm.org>; Richard Smith <richard at
metafoo.co.uk>; cfe-dev at lists.llvm.org
> Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
>  
>  
> On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> 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.
>  
> 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.
>  
> The standard argument against trying to introduce "scope-like"
mechanisms to LLVM IR is inlining; unless you're going to prevent functions
that use stricter/laxer FP rules from being inlined into each other (which
sounds disastrous), you're going to need to communicate strictness on an
instruction-by-instruction basis.  If the backend wants to handle that by using
the strictest rule that it sees in use anywhere in the function because
pattern-matching is otherwise too error-prone, ok, that's its right; but the
IR really should be per-instruction.
>  
> John.
> 
> 
>  
> -Andy
>  
> From: Ulrich Weigand [mailto:Ulrich.Weigand at de.ibm.com
<mailto:Ulrich.Weigand at de.ibm.com>]
> Sent: Tuesday, January 09, 2018 9:59 AM
> To: Kaylor, Andrew <andrew.kaylor at intel.com <mailto:andrew.kaylor
at intel.com>>; kpn at neutralgood.org <mailto:kpn at
neutralgood.org>
> Cc: Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at
anl.gov>>; Richard Smith <richard at metafoo.co.uk <mailto:richard
at metafoo.co.uk>>; bob.huemmer at sas.com <mailto:bob.huemmer at
sas.com>; bumblebritches57 at gmail.com <mailto:bumblebritches57 at
gmail.com>; wei.ding2 at amd.com <mailto:wei.ding2 at amd.com>; cfe-dev
at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>; llvm-dev
<llvm-dev at lists.llvm.org <mailto: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 <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180110/fe19b729/attachment-0001.html>

On 9 Jan 2018 22:55, "John McCall via llvm-dev" <llvm-dev at
lists.llvm.org>
wrote:


On Jan 9, 2018, at 3:50 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:
>The standard argument against trying to introduce "scope-like"
mechanisms
to LLVM IR is inlining;
>unless you're going to prevent functions that use stricter/laxer FP
rules
from being inlined >into
>each other (which sounds disastrous), you're going to need to
communicate
strictness on an
>instruction-by-instruction basis.  If the backend wants to handle that by
using the strictest
>rule that it sees in use anywhere in the function because pattern-matching
is otherwise too
>error-prone, ok, that's its right; but the IR really should be
per-instruction.

I added a function level attribute, strictfp, which is meant to help with
this. I don’t believe the inlining handling of the attribute is implemented
yet, but what I’m thinking is that we would never inline a function that
had the strictfp attribute and if we inlined a non-strictfp function into a
strictfp function, we would transform any FP operations into their
constrained equivalents at that time. In the short term, we’d probably just
block both types of inlining.

It may sound disastrous, but I think there’s an understanding that using
strict FP semantics is going to significantly inhibit optimizations. In the
short term, that’s actually the purpose of the constrained intrinsics -- to
disable all optimizations until we can teach the optimizer to do things
correctly. The plan is that once this is all implemented to produce correct
results, we’ll go back and try to re-enable as many optimizations as
possible, which may eventually include doing something more intelligent
with inlining.

With regard to your “instruction level” comments, my intention is that the
use of the intrinsics will impose the necessary restrictions at the
instruction level. Optimizations (other than inlining) should never need to
check the function level attribute. But if we mixed “raw” FP operations and
constrained intrinsics within a single function there would be no way to
prevent motion of the “raw” operations across the intrinsics.


Is that a problem?  Semantics are guaranteed only for strictfp operations,
i.e. ones that use the intrinsics.  Raw operations can get reordered across
intrinsics and change semantics, but that seems allowable, right?


No. Raw operations must execute in the default FP environment. It's not ok
to reorder a raw fp operation into an FENV_ACCESS region and past a call
that enables an FP exception on overflow, for example.

John.



The reason I brought up the scope level nature of the pragma was just to
suggest that it might be a property that we could take advantage of to
handle the transition from IR to MIR. I haven’t come up with a way to bake
the strict FP information into the instructions across the ISel boundary,
but I think it might be possible to temporarily add it to a block and then
have an early machine code pass that used this information in some way once
the MIR was all in place. I’m open to the possibility that that was a bad
idea.

-Andy


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



On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <
cfe-dev at lists.llvm.org> 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.

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.


The standard argument against trying to introduce "scope-like"
mechanisms
to LLVM IR is inlining; unless you're going to prevent functions that use
stricter/laxer FP rules from being inlined into each other (which sounds
disastrous), you're going to need to communicate strictness on an
instruction-by-instruction basis.  If the backend wants to handle that by
using the strictest rule that it sees in use anywhere in the function
because pattern-matching is otherwise too error-prone, ok, that's its
right; but the IR really should be per-instruction.

John.



-Andy

*From:* Ulrich Weigand [mailto:Ulrich.Weigand at de.ibm.com
<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 <+49%207031%20163727>
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



_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180109/12313fd6/attachment.html>

> On Jan 10, 2018, at 2:22 AM, Richard Smith <richard at metafoo.co.uk>
wrote:
> 
> On 9 Jan 2018 22:55, "John McCall via llvm-dev" <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>> On Jan 9, 2018, at 3:50 PM, Kaylor, Andrew <andrew.kaylor at
intel.com <mailto:andrew.kaylor at intel.com>> wrote:
>> 
>> >The standard argument against trying to introduce
"scope-like" mechanisms to LLVM IR is inlining;
>> >unless you're going to prevent functions that use
stricter/laxer FP rules from being inlined >into
>> >each other (which sounds disastrous), you're going to need to
communicate strictness on an
>> >instruction-by-instruction basis.  If the backend wants to handle
that by using the strictest
>> >rule that it sees in use anywhere in the function because
pattern-matching is otherwise too
>> >error-prone, ok, that's its right; but the IR really should be
per-instruction.
>>  
>> I added a function level attribute, strictfp, which is meant to help
with this. I don’t believe the inlining handling of the attribute is implemented
yet, but what I’m thinking is that we would never inline a function that had the
strictfp attribute and if we inlined a non-strictfp function into a strictfp
function, we would transform any FP operations into their constrained
equivalents at that time. In the short term, we’d probably just block both types
of inlining.
>>  
>> It may sound disastrous, but I think there’s an understanding that
using strict FP semantics is going to significantly inhibit optimizations. In
the short term, that’s actually the purpose of the constrained intrinsics -- to
disable all optimizations until we can teach the optimizer to do things
correctly. The plan is that once this is all implemented to produce correct
results, we’ll go back and try to re-enable as many optimizations as possible,
which may eventually include doing something more intelligent with inlining.
>>  
>> With regard to your “instruction level” comments, my intention is that
the use of the intrinsics will impose the necessary restrictions at the
instruction level. Optimizations (other than inlining) should never need to
check the function level attribute. But if we mixed “raw” FP operations and
constrained intrinsics within a single function there would be no way to prevent
motion of the “raw” operations across the intrinsics.
> 
> Is that a problem?  Semantics are guaranteed only for strictfp operations,
i.e. ones that use the intrinsics.  Raw operations can get reordered across
intrinsics and change semantics, but that seems allowable, right?
> 
> No. Raw operations must execute in the default FP environment. It's not
ok to reorder a raw fp operation into an FENV_ACCESS region and past a call that
enables an FP exception on overflow, for example.
Ah, okay.  In that case, yes, I can understand why you want a stricter rule that
all the operations in a strictfp function must use the intrinsics.

John.
> 
> John.
> 
> 
>>  
>> The reason I brought up the scope level nature of the pragma was just
to suggest that it might be a property that we could take advantage of to handle
the transition from IR to MIR. I haven’t come up with a way to bake the strict
FP information into the instructions across the ISel boundary, but I think it
might be possible to temporarily add it to a block and then have an early
machine code pass that used this information in some way once the MIR was all in
place. I’m open to the possibility that that was a bad idea.
>>  
>> -Andy
>>  
>>   <>
>> From: rjmccall at apple.com <mailto:rjmccall at apple.com>
[mailto:rjmccall at apple.com <mailto:rjmccall at apple.com>]
>> Sent: Tuesday, January 09, 2018 11:12 AM
>> To: Kaylor, Andrew <andrew.kaylor at intel.com
<mailto:andrew.kaylor at intel.com>>
>> Cc: Ulrich Weigand <Ulrich.Weigand at de.ibm.com
<mailto:Ulrich.Weigand at de.ibm.com>>; kpn at neutralgood.org
<mailto:kpn at neutralgood.org>; bumblebritches57 at gmail.com
<mailto:bumblebritches57 at gmail.com>; bob.huemmer at sas.com
<mailto:bob.huemmer at sas.com>; llvm-dev <llvm-dev at lists.llvm.org
<mailto:llvm-dev at lists.llvm.org>>; Richard Smith <richard at
metafoo.co.uk <mailto:richard at metafoo.co.uk>>; cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> Subject: Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
>>  
>>  
>> On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> 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.
>>  
>> 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.
>>  
>> The standard argument against trying to introduce
"scope-like" mechanisms to LLVM IR is inlining; unless you're
going to prevent functions that use stricter/laxer FP rules from being inlined
into each other (which sounds disastrous), you're going to need to
communicate strictness on an instruction-by-instruction basis.  If the backend
wants to handle that by using the strictest rule that it sees in use anywhere in
the function because pattern-matching is otherwise too error-prone, ok,
that's its right; but the IR really should be per-instruction.
>>  
>> John.
>> 
>> 
>>  
>> -Andy
>>  
>> From: Ulrich Weigand [mailto:Ulrich.Weigand at de.ibm.com
<mailto:Ulrich.Weigand at de.ibm.com>]
>> Sent: Tuesday, January 09, 2018 9:59 AM
>> To: Kaylor, Andrew <andrew.kaylor at intel.com
<mailto:andrew.kaylor at intel.com>>; kpn at neutralgood.org
<mailto:kpn at neutralgood.org>
>> Cc: Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at
anl.gov>>; Richard Smith <richard at metafoo.co.uk <mailto:richard
at metafoo.co.uk>>; bob.huemmer at sas.com <mailto:bob.huemmer at
sas.com>; bumblebritches57 at gmail.com <mailto:bumblebritches57 at
gmail.com>; wei.ding2 at amd.com <mailto:wei.ding2 at amd.com>; cfe-dev
at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>; llvm-dev
<llvm-dev at lists.llvm.org <mailto: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
<tel:+49%207031%20163727>
>> 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 <mailto:cfe-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180110/5f030e35/attachment-0001.html>