Kaylor, Andrew via llvm-dev
2019-Nov-14 20:58 UTC
[llvm-dev] RFC: token arguments and operand bundles
Let me clarify. These aren’t intended to be exposed to the user. The user code
that leads to the generation of these intrinsics will be normal floating point
operations combined with either pragmas (such as “STDC FENV_ACCESS ON”) or
command line options (such as the recently introduced “-fp-model=strict”).
The reason I’ve been avoiding normal constant values is that it provides no
information when you’re reading the IR. For example:
%sum = call double @llvm.experimental.constrained.fadd(double %x, double %y, i32
1, i32 2)
What does that mean? You’d need to consult an external reference to have any
idea.
-Andy
From: Jameson Nash <vtjnash at gmail.com>
Sent: Thursday, November 14, 2019 12:27 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: token arguments and operand bundles
From a front-end perspective, I think it'd be preferable if these either got
encoded in the function name or were normal enum value arguments. It's a bit
awkward to expose things to the user that must be constant or of a special type
or in a special metadata slot, since we now need more special support for it. If
the optimization passes couldn't identify a constant value for one of the
arguments, these seem like they can fallback to assuming the most conservative
semantics (of round.dynamic and fpexcept.strict--e.g. don't optimize)
without loss of precision or generality.
-Jameson
On Thu, Nov 14, 2019 at 2:40 PM Kaylor, Andrew via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hello everyone,
I’ve just uploaded a patch (https://reviews.llvm.org/D70261) to introduce a
could of new token types to be used with constrained floating point intrinsics
and, optionally, vector predicated intrinsics. These intrinsics may not be of
interest to many of you, but I have a more general question.
I would like some general feedback on the way I am proposing to use token
arguments and operand bundles. I have an incomplete understanding of how these
are intended to be used, and I want to make sure what I have in mind is
consistent with the philosophy behind them.
Currently, the constrained floating point intrinsics require string metadata
arguments to describe the rounding mode and exception semantics. These
“arguments” are really providing information to the optimizer about what it can
and cannot assume when acting on these intrinsics. The rounding mode argument
potentially overrides the default optimizer assumption that the “to nearest”
rounding mode is in use, and the exception behavior argument overrides the
default optimizer assumption that floating point operations have no side
effects. I’ve never liked the use of strings here, and the fact that these
arguments are not actually inputs to the operation represented by the intrinsic
seems vaguely wrong.
A typical call to a current intrinsic looks like this:
%sum = call double @llvm.experimental.constrained.fadd(double %x,
double %y,
Metadata
“fpround.dynamic”,
Metadata
“fpexcept.strict”)
The idea I am pursuing in my patch is to replace these metadata arguments with
optional operand bundles, “fpround” and “fpexcept”. If the operand bundles are
present, they would mean what the arguments currently mean. If not, the default
assumption is allowed. A typical call to a constrained intrinsic would look like
this:
%sum = call double @llvm.experimental2.constrained.fadd(double %x,
double %y) [
“fpround”(token rmDynamic),
“fpexcept”(token ebStrict) ]
Does that seem like a valid use of tokens and operand bundles? Does it seem
better than the current approach?
Thanks,
Andy
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://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/20191114/39ce6517/attachment-0001.html>
Jameson Nash via llvm-dev
2019-Nov-15 04:00 UTC
[llvm-dev] RFC: token arguments and operand bundles
I understand that, but I think you missed my point. Not all front-ends are clang, and non-C frontends are also interested in this work. And even C might want to eventually want to be able to use these more generally. For example, the current C standard (afaik) doesn’t define what must happen if this pragma tried to use a non-literal constant, such as a template attribute as the arguments. But it’s not obvious to me why LLVM should inherit that limitation. Currently it seems to be implemented in a way that requires special handling in any front-end, influenced strong by the special handling it’s now getting in C. For other languages, it’s doable to expose this to users regardless, but if you’re already considering changing it, my vote would be to use a normal representation with first-class values. However, I really appreciate the specifics on the concern you brought up, because that’s a good point. If it’s just about better IR printing, perhaps we can just address that directly? Most simply, perhaps these calls could customize the printing to append a comment? Some places already do that, for example to show Function Attributes. Similarly, but more major, LLVM could perhaps define a new “named constant” syntax for the parser format (either with special tokens like your current PR and/or that get defined elsewhere like existing global constants). Certain instructions (such as these) could then use the option to customize the printing of their arguments to use the named constant (after parsing, they’d just be a normal Constant—only printing would optionally use them to show the information better to the reader). Thu, Nov 14, 2019 at 15:58 Kaylor, Andrew <andrew.kaylor at intel.com> wrote:> Let me clarify. These aren’t intended to be exposed to the user. The user > code that leads to the generation of these intrinsics will be normal > floating point operations combined with either pragmas (such as “STDC > FENV_ACCESS ON”) or command line options (such as the recently introduced > “-fp-model=strict”). > > The reason I’ve been avoiding normal constant values is that it provides > no information when you’re reading the IR. For example: > > *%sum = call double @llvm*.experimental.constrained.fadd(double %x, > double %y, i32 1, i32 2) > > What does that mean? You’d need to consult an external reference to have > any idea. > > > > -Andy > > > > *From:* Jameson Nash <vtjnash at gmail.com> > *Sent:* Thursday, November 14, 2019 12:27 PM > *To:* Kaylor, Andrew <andrew.kaylor at intel.com> > *Cc:* LLVM Developers Mailing List <llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] RFC: token arguments and operand bundles > > > > From a front-end perspective, I think it'd be preferable if these either > got encoded in the function name or were normal enum value arguments. It's > a bit awkward to expose things to the user that must be constant or of a > special type or in a special metadata slot, since we now need more special > support for it. If the optimization passes couldn't identify a constant > value for one of the arguments, these seem like they can fallback to > assuming the most conservative semantics (of round.dynamic and > fpexcept.strict--e.g. don't optimize) without loss of precision or > generality. > > > > -Jameson > > > > On Thu, Nov 14, 2019 at 2:40 PM Kaylor, Andrew via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hello everyone, > > > > I’ve just uploaded a patch (https://reviews.llvm.org/D70261) to introduce > a could of new token types to be used with constrained floating point > intrinsics and, optionally, vector predicated intrinsics. These intrinsics > may not be of interest to many of you, but I have a more general question. > > > > I would like some general feedback on the way I am proposing to use token > arguments and operand bundles. I have an incomplete understanding of how > these are intended to be used, and I want to make sure what I have in mind > is consistent with the philosophy behind them. > > > > Currently, the constrained floating point intrinsics require string > metadata arguments to describe the rounding mode and exception semantics. > These “arguments” are really providing information to the optimizer about > what it can and cannot assume when acting on these intrinsics. The rounding > mode argument potentially overrides the default optimizer assumption that > the “to nearest” rounding mode is in use, and the exception behavior > argument overrides the default optimizer assumption that floating point > operations have no side effects. I’ve never liked the use of strings here, > and the fact that these arguments are not actually inputs to the operation > represented by the intrinsic seems vaguely wrong. > > > > A typical call to a current intrinsic looks like this: > > > > *%sum = call double @llvm*.experimental.constrained.fadd(double %x, > > double %y, > > Metadata > “fpround.dynamic”, > > Metadata > “fpexcept.strict”) > > > > The idea I am pursuing in my patch is to replace these metadata arguments > with optional operand bundles, “fpround” and “fpexcept”. If the operand > bundles are present, they would mean what the arguments currently mean. If > not, the default assumption is allowed. A typical call to a constrained > intrinsic would look like this: > > > > *%sum = call double @llvm*.experimental2.constrained.fadd(double %x, > > double %y) [ > “fpround”(token rmDynamic), > > > “fpexcept”(token ebStrict) ] > > > > Does that seem like a valid use of tokens and operand bundles? Does it > seem better than the current approach? > > > > Thanks, > > Andy > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://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/20191114/ec0db97a/attachment.html>
Simon Moll via llvm-dev
2019-Nov-15 11:12 UTC
[llvm-dev] RFC: token arguments and operand bundles
Hi,
@Andy, thanks for the RFC and being open to discussion regarding the constrained
fp encoding.
On 11/15/19 5:00 AM, Jameson Nash via llvm-dev wrote:
I understand that, but I think you missed my point. Not all front-ends are
clang, and non-C frontends are also interested in this work. And even C might
want to eventually want to be able to use these more generally. For example, the
current C standard (afaik) doesn't define what must happen if this pragma
tried to use a non-literal constant, such as a template attribute as the
arguments. But it's not obvious to me why LLVM should inherit that
limitation. Currently it seems to be implemented in a way that requires special
handling in any front-end, influenced strong by the special handling it's
now getting in C. For other languages, it's doable to expose this to users
regardless, but if you're already considering changing it, my vote would be
to use a normal representation with first-class values.
Constrained FP rounding mode and exception args do **not** specify the rounding
mode or exception behavior - the parameters simply explain to LLVM how the
operations behave so they can be analyzed/optimized under that assumption. The
actual fp environment is configured by other means. As such there is little
value in allowing variable exception/rounding mode params for the contrained fp
intrinsics - LLVM passes wouldn't understand them (in all but trivial cases)
and would have to assume the worst case (dynamic/strict) anyway.
Besides, there is no going back from dynamic fpexcept/fpround to constants but
we can always opt in when the need arises.
I guess the exact meaning of the fpround and fpexcept params could be explained
better in the LangRef.
However, I really appreciate the specifics on the concern you brought up,
because that's a good point. If it's just about better IR printing,
perhaps we can just address that directly?
Most simply, perhaps these calls could customize the printing to append a
comment? Some places already do that, for example to show Function Attributes.
Similarly, but more major, LLVM could perhaps define a new "named
constant" syntax for the parser format (either with special tokens like
your current PR and/or that get defined elsewhere like existing global
constants). Certain instructions (such as these) could then use the option to
customize the printing of their arguments to use the named constant (after
parsing, they'd just be a normal Constant-only printing would optionally use
them to show the information better to the reader).
To me it seems constant tokens do the job just fine without the need for a
custom code path.
A typical call to a current intrinsic looks like this:
%sum = call double @llvm.experimental.constrained.fadd(double %x,
double %y,
Metadata
"fpround.dynamic",
Metadata
"fpexcept.strict")
Does that seem like a valid use of tokens and operand bundles? Does it seem
better than the current approach?
I really like the operand bundle approach because it makes the round/except
parameters optional. Basically, a llvm.experimental.constrained.fadd(%x, %y)
without the operand bundle (and without the 'strictfp' attribute -
hypothetically) would lower directly to an 'fadd'. At least that is the
way i am planning to use it for vector-predicated fp ops.
Cheers,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/2863f8e5/attachment.html>
Kaylor, Andrew via llvm-dev
2019-Nov-15 20:16 UTC
[llvm-dev] RFC: token arguments and operand bundles
We really have been trying to keep in mind that LLVM needs to support multiple
front ends, which may be implementing different language standards. As much as
possible, I’ve been trying to let the IEEE 754 spec drive my thinking about
this, though I’ll admit that on a few points I’ve use the C99 spec as a sort of
reference interpretation of IEEE 754.
LLVM’s IRBuilder has been recently updated to provide an abstraction layer
between front ends and the optimizer. So, if you’re using IRBuilder, you set
need to call setIsFPConstrained() then, optionally,
IRBuilder::setDefaultConstraiedExcept() and/or setDefaultConstrainedRounding().
After that, calls to something like IRBuilder::CreateFAdd() will automatically
create the constrained intrinsic with the appropriate constraints, regardless of
how we end up representing them. If your front end isn’t using IRBuilder, I will
admit it gets a bit more complicated.
I wouldn’t be opposed to a solution that involved a custom printer for these
arguments, but I don’t think it really adds anything that we wouldn’t get from
using tokens as I have proposed. Likewise with the named constant idea. On the
other hand, if I’m misusing tokens then maybe what constants would add is a way
to avoid that misuse.
Regarding the question of what is exposed to users and how, that’s mostly up to
the front end. I would like to clarify how we intend for this to work, in
general. Simon touched on this briefly, but I’d like to be a bit more verbose to
make sure we’re all on the same page.
There are effectively two distinct modes of source code translation to IR with
respect to floating point operations -- one where the user is allowed to modify
the floating point environment and one where they are not. This may not have
been clear to everyone, but by default LLVM IR carries with it the assumption
that the runtime rounding mode is “to nearest” and that floating point
operations do not have side effects. This was only documented recently, but this
is the way the optimizer has always behaved. In this default mode, the IR
*shouldn’t* change the floating point environment. I would encourage front ends
to document this more specifically saying that the user is not permitted to
change the FP environment.
This leads to the necessity of a second state in which the optimizer does not
assume the default rounding mode and does not assume that floating point
operations have no side effects. Proscribing these assumptions limits
optimization, so we want to continue allowing the assumptions by default. The
state where the assumptions are not made is accomplished through the use of
constrained intrinsics. However, we do not wish to completely eliminate
optimizations in all cases, so we want a way to communicate to the optimizer
what it can assume. That is the purpose of the fpround and fpexcept arguments.
These are not intended to control the rounding mode or exception reporting. They
only tell the compiler what it can assume.
Understanding this, front ends can control these in any way they see fit. For
instance, the front end might have a global setting the changes the rounding
mode to “toward zero.” In that case, it would create constrained intrinsics for
all FP operations and set the rounding mode argument (however we end up
representing in) to rmTowardZero (a constant currently defined by LLVM
corresponding to the “fpround.towardzero” metadata argument). Then the
optimizer can use this information to perform optimizations like constant
folding.
Runtime changes to the rounding mode are a separate matter. As I said above, I
think front ends should define clear circumstances under which such changes are
permitted, but the mechanism for making such changes is independent of the
constrained FP intrinsics. For example, consider the following C function.
double foo(double A, double B, double C) {
int OrigRM = fegetround();
fesetround(FE_TOWARDZERO);
double tmp = A + B;
fesetround(OrigRM);
return tmp + C;
}
Assuming the compiler was in a state where it knew fenv access was enabled, I
would expect that to get translated to something like this (after SROA cleanup):
define double @foo(double %A, double %B, double %C) {
%orig.rm = call i32 @fegetround()
%ignored = call i32 @fesetround(i32 3072)
%tmp = call double @llvm.experimental.constrained.fadd(double %A, double %B) [
“fpround”(token rmDynamic), “fpexcept”(token rmStrict) ]
%ignored = call i32 @fesetround(i32 %orig.rm)
%result = call double @llvm.experimental.constrained.fadd(double %tmp, double
%C) [ “fpround”(token rmDynamic), “fpexcept”(token rmStrict) ]
}
Notice here the literal constant that C defines is still used for the call to
fesetround(FE_TOWARDZERO), and the variable is used for the call that restores
the rounding mode. Also notice that in both fadd operations, the rounding mode
is declared as rmDynamic. I have an idea that we ought to have a pass that
recognizes the fesetround library call an uses the information it finds there to
change the rounding mode operand in the first fadd to rmTowardZero, but the
front end won’t be expected to do that. We’ll probably want an intrinsic to
change the rounding mode so that we don’t need to recognize all manner of
language-specific libcalls, but that’s a problem for later.
I hope this has been more helpful than tedious. Also, I feel like I should
reiterate that I am still seeking all opinions about the use of tokens and
operand bundles or any other means of representing the fp constraints. I just
want to make sure that we all have the same understanding of what the
information I’m trying to represent in IR means.
-Andy
From: Jameson Nash <vtjnash at gmail.com>
Sent: Thursday, November 14, 2019 8:00 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: token arguments and operand bundles
I understand that, but I think you missed my point. Not all front-ends are
clang, and non-C frontends are also interested in this work. And even C might
want to eventually want to be able to use these more generally. For example, the
current C standard (afaik) doesn’t define what must happen if this pragma tried
to use a non-literal constant, such as a template attribute as the arguments.
But it’s not obvious to me why LLVM should inherit that limitation. Currently it
seems to be implemented in a way that requires special handling in any
front-end, influenced strong by the special handling it’s now getting in C. For
other languages, it’s doable to expose this to users regardless, but if you’re
already considering changing it, my vote would be to use a normal representation
with first-class values.
However, I really appreciate the specifics on the concern you brought up,
because that’s a good point. If it’s just about better IR printing, perhaps we
can just address that directly?
Most simply, perhaps these calls could customize the printing to append a
comment? Some places already do that, for example to show Function Attributes.
Similarly, but more major, LLVM could perhaps define a new “named constant”
syntax for the parser format (either with special tokens like your current PR
and/or that get defined elsewhere like existing global constants). Certain
instructions (such as these) could then use the option to customize the printing
of their arguments to use the named constant (after parsing, they’d just be a
normal Constant—only printing would optionally use them to show the information
better to the reader).
Thu, Nov 14, 2019 at 15:58 Kaylor, Andrew <andrew.kaylor at
intel.com<mailto:andrew.kaylor at intel.com>> wrote:
Let me clarify. These aren’t intended to be exposed to the user. The user code
that leads to the generation of these intrinsics will be normal floating point
operations combined with either pragmas (such as “STDC FENV_ACCESS ON”) or
command line options (such as the recently introduced “-fp-model=strict”).
The reason I’ve been avoiding normal constant values is that it provides no
information when you’re reading the IR. For example:
%sum = call double @llvm.experimental.constrained.fadd(double %x, double %y, i32
1, i32 2)
What does that mean? You’d need to consult an external reference to have any
idea.
-Andy
From: Jameson Nash <vtjnash at gmail.com<mailto:vtjnash at
gmail.com>>
Sent: Thursday, November 14, 2019 12:27 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at
intel.com>>
Cc: LLVM Developers Mailing List <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Subject: Re: [llvm-dev] RFC: token arguments and operand bundles
From a front-end perspective, I think it'd be preferable if these either got
encoded in the function name or were normal enum value arguments. It's a bit
awkward to expose things to the user that must be constant or of a special type
or in a special metadata slot, since we now need more special support for it. If
the optimization passes couldn't identify a constant value for one of the
arguments, these seem like they can fallback to assuming the most conservative
semantics (of round.dynamic and fpexcept.strict--e.g. don't optimize)
without loss of precision or generality.
-Jameson
On Thu, Nov 14, 2019 at 2:40 PM Kaylor, Andrew via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Hello everyone,
I’ve just uploaded a patch (https://reviews.llvm.org/D70261) to introduce a
could of new token types to be used with constrained floating point intrinsics
and, optionally, vector predicated intrinsics. These intrinsics may not be of
interest to many of you, but I have a more general question.
I would like some general feedback on the way I am proposing to use token
arguments and operand bundles. I have an incomplete understanding of how these
are intended to be used, and I want to make sure what I have in mind is
consistent with the philosophy behind them.
Currently, the constrained floating point intrinsics require string metadata
arguments to describe the rounding mode and exception semantics. These
“arguments” are really providing information to the optimizer about what it can
and cannot assume when acting on these intrinsics. The rounding mode argument
potentially overrides the default optimizer assumption that the “to nearest”
rounding mode is in use, and the exception behavior argument overrides the
default optimizer assumption that floating point operations have no side
effects. I’ve never liked the use of strings here, and the fact that these
arguments are not actually inputs to the operation represented by the intrinsic
seems vaguely wrong.
A typical call to a current intrinsic looks like this:
%sum = call double @llvm.experimental.constrained.fadd(double %x,
double %y,
Metadata
“fpround.dynamic”,
Metadata
“fpexcept.strict”)
The idea I am pursuing in my patch is to replace these metadata arguments with
optional operand bundles, “fpround” and “fpexcept”. If the operand bundles are
present, they would mean what the arguments currently mean. If not, the default
assumption is allowed. A typical call to a constrained intrinsic would look like
this:
%sum = call double @llvm.experimental2.constrained.fadd(double %x,
double %y) [
“fpround”(token rmDynamic),
“fpexcept”(token ebStrict) ]
Does that seem like a valid use of tokens and operand bundles? Does it seem
better than the current approach?
Thanks,
Andy
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://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/20191115/f73a052a/attachment-0001.html>