llvm dev - Jan 2018 - [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180109/32a34b83/attachment.html>

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.

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180109/67283e12/attachment-0001.html>

> 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>

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

Hi Andrew,

sorry for the delay, I only now got some time to look into this a bit more.
But I still have a number of questions of how to actually implement this in
the back end.  Looking at this bottom-up, starting with the behavior of the
actual machine instructions, we have (at least on SystemZ) the following
things to consider:

A) Rounding mode

Most FP arithmetic instructions use the "current rounding mode" as
indicated in the floating-point control register.  This is currently
assumed to never change.  To fix this, we need to avoid scheduling FP
arithmetic instructions across instructions that modify the rounding mode.
This may also imply avoiding scheduling instructions across function calls,
since those may also modify the rounding mode.  This can probably be done
by modeling the floating-point control register as LLVM register (or maybe
model just the rounding mode bits as its own "register"), have all FP
arithmetic instructions in question take this new register as implicit
input, and have the register by clobbered by the instructions that change
the rounding mode (and also function calls).

B) Floating-point status flags

FP instructions set a flag bit in the floating-point status register
whenever an IEEE exception condition is recognized.  If these flag bits are
later tested by application code, we should ensure their value is unchanged
by compiler optimization.  Naively modeling the status register is probably
overkill here: since every FP instruction would need to be considered to
modify (i.e. use and def) that register, this simply has the effect of
creating a dependency chain across *all* FP instructions and makes any kind
of instruction scheduling impossible.  But this isn't really necessary
since the flag bits actually simply accumulate.  So it would suffice to
have special dependencies from each FP instruction separately directly to
the next instruction (or routine) that reads the status flags. However, I
don't really see any easy way to model this type of dependency in the
back-end (in particular on the MI level).

C) Floating-point exceptions

If a mask bit in the floating-point status register is set, then all FP
instructions will *trap* whenever an IEEE exception condition is
recognized.  This means that we need to treat those instructions as having
unmodelled side effects, so that they cannot be speculatively executed.
Also, we cannot schedule FP instructions across instructions that set
(those bits in) the FP status register -- but the latter is probably
automatically done as long as those latter instructions are described as
having unmodeled side effects.   Note that this will in effect again create
a dependency chain across all FP instructions, so that B) should be
implicitly covered as well here.

Did I miss anything here?  I'm assuming that the behavior on FP
instructions on Intel (and other architectures) will be roughly similar,
given that this behavior is mostly defined by the IEEE standard.


Now the question in my mind is, how this this all map onto the experimental
constrained intrinsics?   They do have "rounding mode" and
"exception
behavior" metadata, but I don't really see how that maps onto the
behavior
of instructions as described above.   Also, right now the back-end doesn't
even *get* at that data in the first place, since it is just thown away
when lowering the intrinsics to STRICT_... nodes.   In fact, I'm also not
sure how the front-end is even supposed to be *setting* those metadata
flags -- is the compiler supposed to track calls to fesetround and the
like, and thereby determine which rounding and exception modes apply to any
given block of code?  In fact, was the original intention even that the
back-end actually implements different behavior based on this level of
detail, or was the back-end supposed to support only two modes, the default
behavior of today and a fully strict implementation always satisfying all
three of A), B), and C) above?

Looking again at a possible implementation in the back-end, I'm now
wondering if it wouldn't after all be better to just treat the STRICT_
opcodes like all other DAG nodes.  That is, have them be associated with an
action (Legal, Expand, or Custom); set the default action to Expand, with a
default expander that just replaces them by the "normal" FP nodes; and
allow a back-end to set the action to Legal and/or Custom and then just
handle them in the back-end as it sees fit.  This might indeed require
multiple patterns to match them, but it should be possible to generate
those via multiclass instantiations so it might not be all that big a deal.
The benefit would be that it allows the back-end the greatest freedom how
to handle things (e.g. interactions with target-specific control
registers).


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



From:	"Kaylor, Andrew" <andrew.kaylor at intel.com>
To:	Ulrich Weigand <Ulrich.Weigand at de.ibm.com>,
            "kpn at neutralgood.org" <kpn at neutralgood.org>
Cc:	Hal Finkel <hfinkel at anl.gov>, Richard Smith
            <richard at metafoo.co.uk>, "bob.huemmer at sas.com"
            <bob.huemmer at sas.com>, "bumblebritches57 at
gmail.com"
            <bumblebritches57 at gmail.com>, "cfe-dev at
lists.llvm.org"
            <cfe-dev at lists.llvm.org>, llvm-dev <llvm-dev at
lists.llvm.org>
Date:	09.01.2018 19:55
Subject:	RE: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?



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.

-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





-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/327ca6c1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/327ca6c1/attachment.gif>

Oh, and other thing:   Are you planning to attend the upcoming LLVM
developer's meeting in Bristol?  I thought it might be good idea to get all
parties interested in this feature together in person, if we're at the same
meeting anyway.  So I was thinking of submitting a proposal for a BoF
session on this topic ...


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



From:	"Kaylor, Andrew" <andrew.kaylor at intel.com>
To:	Ulrich Weigand <Ulrich.Weigand at de.ibm.com>,
            "kpn at neutralgood.org" <kpn at neutralgood.org>
Cc:	Hal Finkel <hfinkel at anl.gov>, Richard Smith
            <richard at metafoo.co.uk>, "bob.huemmer at sas.com"
            <bob.huemmer at sas.com>, "bumblebritches57 at
gmail.com"
            <bumblebritches57 at gmail.com>, "cfe-dev at
lists.llvm.org"
            <cfe-dev at lists.llvm.org>, llvm-dev <llvm-dev at
lists.llvm.org>
Date:	09.01.2018 19:55
Subject:	RE: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?



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.

-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





-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/a5046b72/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/a5046b72/attachment.gif>