<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/2/19 5:12 PM, Hal Finkel wrote:<br>
</div>
<blockquote type="cite" cite="mid:f4c88cd2-f2b1-2a12-9133-8e23f0e2134c@anl.gov">
<div class="moz-cite-prefix">On 10/1/19 12:35 AM, Serge Pavlov via llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:CACOhrX6ZssUNLFxX7i2anO6eADYFchVjLjHm2bFfDi=-XgWhEQ@mail.gmail.com">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>This proposal is aimed at support of floating point environment, in which some properties like rounding mode or exception behavior differ from those used by default. This include in particular support of 'pragma STDC FENV_ACCESS', 'pragma STDC FENV_ROUND'
as well as some other related facilities.<br>
<br>
Problem<br>
<br>
On many processors use of non-default floating mode requires modification of global state by writing into some register. It presents a difficulty for implementation as a floating point instruction must not be move to code which executes with different floating
point state. To prevent from such moves, the current solution represents FP operations with special (constrained) instructions, which do not participate in optimizations (<a href="http://lists.llvm.org/pipermail/cfe-dev/2017-August/055325.html" moz-do-not-send="true">http://lists.llvm.org/pipermail/cfe-dev/2017-August/055325.html</a>).
It is important that the constrained FP operations must be used everywhere in entire function including inlined calls, if they are used in some part of it.<br>
<br>
The main concern about such approach is performance drop. Using constrained FP operations means that optimizations on FP operations are turned off, this is the main reason of using them. Even if non-default FP environment is used in a small piece of a function,
optimizations are turned off in entire function. For many practical application this is unacceptable.<br>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>The reason, as you're likely aware, that the constrained FP operations must be used within the entire function is that, if you mix the constrained FP operations with the normal ones, there's no way to prevent code motion from intermixing them. The solution
I recall being discussed to this problem of a function which requires constrained operations only in part is outlining in Clang - this does introduce function-call overhead (although perhaps some MI-level inlining pass could mitigate that in part), but otherwise
permits normal optimization of the normal FP operations.<br>
</p>
</blockquote>
<p><br>
</p>
<p>Johannes and I discussed the outlining here offline, and two notes:</p>
<p> 1. The outlining itself will prevent the undesired code motion today, but in the future we'll have IPO transformations that will need to be specifically taught to avoid moving FP operations into these outlined functions.</p>
<p> 2. The outlined functions will need to be marked with noinline and also noimplicitfloat. In fact, all functions using the constrained intrinsics might need to be marked with noimplicitfloat. The above-mentioned restrictions on IPO passes might be conditioned
on the noimplicitfloat attribute.</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:f4c88cd2-f2b1-2a12-9133-8e23f0e2134c@anl.gov">
<p></p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CACOhrX6ZssUNLFxX7i2anO6eADYFchVjLjHm2bFfDi=-XgWhEQ@mail.gmail.com">
<div dir="ltr">
<div><br>
Although this approach prevents from moving instructions, it does not prevent from moving basic blocks. The code that uses non-default FP environment at some point must set appropriate state registers, do necessary operations and then restore the original mode.
If this activity is scattered by several basic blocks, block-level optimizations can break these arrangement, for instance a basic block with default FP operations can be moved after the block that sets non-default FP environment.<br>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Can you please provide some pseudocode to illustrate this problem? Moving basic blocks moves the instructions within them, and I don't see how our current semantics would prevent illegal reorderings of the instructions but not prevent illegal reorderings
of groups of those same instructions. At the LLVM level, we currently model the FP-environment state as a kind of memory, and so the operations which adjust the FP-environment state must also be marked as writing to memory, but that's true with essentially
all external program state, and that should prevent all illegal reordering.</p>
<p>Thanks,</p>
<p>Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CACOhrX6ZssUNLFxX7i2anO6eADYFchVjLjHm2bFfDi=-XgWhEQ@mail.gmail.com">
<div dir="ltr">
<div><br>
Solution<br>
<br>
The proposed approach is based on extension of basic blocks. It is assumed that code in basic block is executed in the same FP environment. The assumption is consistent with the rules of using 'pragma STDC FENV_ACCESS' and similar facilities. If the environment
differs from default, such block has pointer to some object that keeps the block attributes including FP settings. All basic blocks, obtained from the same block where 'pragma STDC FENV_ACCESS' is specified, share the same attribute object. In bytecode these
attributes are represented by metadata attached to the basic blocks.<br>
<br>
With basic block attributes compiler can assert validity of an instruction move by comparing attributes of source and destination BBs. An instruction should keep pointer to BB attributes even if it is detached from BB, to support common technique of moving
instructions. Similarly compiler can verify validity of BB movement.<br>
<br>
Such approach allows to develop implementation in which constrained FP operations are 'jailed' in their basic blocks. Other part of the function can still use usual FP operations and get profit of optimizations. Depending on the target hardware some FP operations
may be allowed to cross the 'jail' boundary, for instance, it they correspond to instructions which directly encode rounding mode and FP environment change rounding mode only.<br>
<br>
Is this solution feasible? What are obstacles, difficulties or drawbacks for it? Are there any improvements for it? Any feedback is welcome.</div>
<div><br clear="all">
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Thanks,<br>
--Serge<br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>