Page MenuHomePhabricator

kpn (Kevin P. Neal)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 20 2018, 9:31 AM (65 w, 1 h)

Recent Activity

Today

kpn updated subscribers of D43515: More math intrinsics for conservative math handling.
Tue, May 21, 6:28 AM

Wed, May 15

kpn added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

I'm waiting for a signoff from at least one front-end guy. I hope the mode setting that allows us to keep front ends from having to touch every use of the IRBuilder is something that works for clang. But I haven't heard anything from @rsmith or any other front-end person.

Wed, May 15, 1:14 PM
kpn added a comment to D43515: More math intrinsics for conservative math handling.

The only thing left in this ticket to commit is the fptosi and fptoui changes. I'm working on incorporating review comments from D55897 into this ticket and fixing other bugs that I'm coming across. I'll hopefully update this ticket next week.

Wed, May 15, 10:55 AM
kpn added a comment to D61916: Teach InstSimplify transform -X + X --> 0.0 about unary FNeg.

If I recall, fneg is not a constrained intrinsic because an fneg will never itself trap.

Wed, May 15, 9:39 AM · Restricted Project
kpn added a comment to D61916: Teach InstSimplify transform -X + X --> 0.0 about unary FNeg.

Is this an allowed transform?

Wed, May 15, 5:38 AM · Restricted Project

Mon, May 13

kpn committed rG5987749e33bb: Add constrained fptrunc and fpext intrinsics. (authored by kpn).
Add constrained fptrunc and fpext intrinsics.
Mon, May 13, 6:24 AM
kpn committed rL360581: Add constrained fptrunc and fpext intrinsics..
Add constrained fptrunc and fpext intrinsics.
Mon, May 13, 6:21 AM
kpn closed D55897: Add constrained fptrunc and fpext intrinsics.
Mon, May 13, 6:21 AM · Restricted Project

Fri, May 10

kpn added a comment to D55897: Add constrained fptrunc and fpext intrinsics.

Excellent. Thank you for all the reviews! I will commit this on Monday morning so I can keep an eye on the bots.

Fri, May 10, 1:43 PM · Restricted Project
kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

Address review comments.

Fri, May 10, 1:31 PM · Restricted Project
kpn updated subscribers of D53157: Teach the IRBuilder about constrained fadd and friends.
Fri, May 10, 12:35 PM
kpn updated subscribers of D43515: More math intrinsics for conservative math handling.
Fri, May 10, 12:32 PM
kpn updated subscribers of D55897: Add constrained fptrunc and fpext intrinsics.
Fri, May 10, 12:32 PM · Restricted Project
kpn added a reviewer for D53157: Teach the IRBuilder about constrained fadd and friends: rsmith.
Fri, May 10, 10:18 AM

Thu, May 9

kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

Why does Verifier::visitIntrinsicCall() not choke when given an intrinsic it doesn't know about?

Thu, May 9, 12:57 PM · Restricted Project
kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

Address review comments: Add a comment as requested. Remove bogus optimizations to let the base case work. Update tests.

Thu, May 9, 9:46 AM · Restricted Project

Fri, May 3

kpn added a comment to D61447: [FPEnv] WIP on threading fneg through llvm.

@spatel I'm not a PatternMatch expert, but I think that change is what we wanted. That is, to continue to match FSub(-0.0, X) as an FNeg(X).

Just FYI that an equivalent patch was made to the PatternMatcher in D61520. I needed this for some FNeg constant folding work. Thanks for the inspirations, Kevin.

Fri, May 3, 9:54 AM · Restricted Project

Thu, May 2

kpn created D61447: [FPEnv] WIP on threading fneg through llvm.
Thu, May 2, 9:24 AM · Restricted Project

Wed, May 1

kpn added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Wed, May 1, 10:07 AM · Restricted Project

Mon, Apr 29

kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

Address review comments.

Mon, Apr 29, 9:50 AM · Restricted Project
kpn committed rGa25c92830219: Add AVX support to this test. (authored by kpn).
Add AVX support to this test.
Mon, Apr 29, 9:05 AM
kpn committed rL359461: Add AVX support to this test..
Add AVX support to this test.
Mon, Apr 29, 9:04 AM

Fri, Apr 26

kpn added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Fri, Apr 26, 7:58 AM · Restricted Project

Thu, Apr 25

kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

Address review comments.

Thu, Apr 25, 11:20 AM · Restricted Project

Apr 17 2019

kpn added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

Would it make sense to also update docs/AddingConstrainedIntrinsics.rst please?

Apr 17 2019, 12:28 PM · Restricted Project
kpn added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Apr 17 2019, 9:47 AM · Restricted Project

Apr 11 2019

kpn committed rG339594e4dc10: New document skeleton describing how to add a constrained floating-point… (authored by kpn).
New document skeleton describing how to add a constrained floating-point…
Apr 11 2019, 10:16 AM
kpn committed rL358194: New document skeleton describing how to add a constrained floating-point.
New document skeleton describing how to add a constrained floating-point
Apr 11 2019, 10:16 AM
kpn closed D59833: [FPEnv] New document for adding new constrained FP intrinsics.
Apr 11 2019, 10:16 AM · Restricted Project

Apr 10 2019

kpn updated the diff for D59833: [FPEnv] New document for adding new constrained FP intrinsics.
Apr 10 2019, 10:56 AM · Restricted Project
kpn added inline comments to D59833: [FPEnv] New document for adding new constrained FP intrinsics.
Apr 10 2019, 10:56 AM · Restricted Project

Mar 27 2019

kpn committed rG4f3cdc6555ca: The IR verifier currently supports the constrained floating point intrinsics… (authored by kpn).
The IR verifier currently supports the constrained floating point intrinsics…
Mar 27 2019, 6:30 AM
kpn committed rL357065: The IR verifier currently supports the constrained floating point intrinsics,.
The IR verifier currently supports the constrained floating point intrinsics,
Mar 27 2019, 6:30 AM
kpn closed D59830: [FPEnv] Make constrained FP IR verification more flexible..
Mar 27 2019, 6:30 AM · Restricted Project

Mar 26 2019

kpn updated the diff for D59830: [FPEnv] Make constrained FP IR verification more flexible..

Remove some unneeded, untested code and add a comment on why it is unneeded.

Mar 26 2019, 12:32 PM · Restricted Project
kpn created D59833: [FPEnv] New document for adding new constrained FP intrinsics.
Mar 26 2019, 12:00 PM · Restricted Project
kpn added a comment to D59830: [FPEnv] Make constrained FP IR verification more flexible..

No new observable behavior change is introduced by this patch. I believe the existing constrained intrinsic tests should exercise it pretty well. Is there a specific test that is needed?

Mar 26 2019, 11:45 AM · Restricted Project
kpn created D59830: [FPEnv] Make constrained FP IR verification more flexible..
Mar 26 2019, 11:34 AM · Restricted Project
kpn added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Mar 26 2019, 7:57 AM · Restricted Project

Mar 18 2019

kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

Rebase. Ping.

Mar 18 2019, 10:04 AM · Restricted Project

Feb 25 2019

kpn added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

I think we can have a flag to indicate rounding mode for float operator such as FADD instead of STRICT_FADD, because STRICT_FADD does have side effect(chain), but some target (eg. RISCV) has static rounding mode encoded in the instruction which does not side effect. Then we can optimize specific STRICT_FADD node which ignoring exception into normal FADD with corresponding static round mode.

Feb 25 2019, 6:44 AM

Feb 18 2019

kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

Address review comments.

Feb 18 2019, 11:34 AM · Restricted Project
kpn added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Feb 18 2019, 11:32 AM · Restricted Project

Feb 8 2019

kpn added a comment to D57875: [LegalizeTypes] Expand FNEG to bitwise op for IEEE FP types.

Without this patch is the fneg instruction getting turned into a subtraction instruction? I hope not on any platform!

Feb 8 2019, 12:33 PM · Restricted Project
kpn added a comment to D55897: Add constrained fptrunc and fpext intrinsics.

I'm seeing a regression in WebAssembly/PR40267.ll that I need to look into. If anyone else is seeing this failure let me know.

Feb 8 2019, 10:11 AM · Restricted Project

Feb 5 2019

kpn added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

I emailed llvm-dev and cfe-dev on January 16th. The only responses I got back were of the don't care variety. For now it seems the constrained intrinsics will only be used by clang.

Feb 5 2019, 9:57 AM
kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

Address review comments.

Feb 5 2019, 9:49 AM · Restricted Project
kpn added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Feb 5 2019, 9:46 AM · Restricted Project

Jan 29 2019

kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

Add back a rounding mode argument to constrained fptrunc as requested by Connor Abbott.

Jan 29 2019, 11:02 AM · Restricted Project
kpn added a comment to D55897: Add constrained fptrunc and fpext intrinsics.

OK, I'm working on it now.

Jan 29 2019, 7:19 AM · Restricted Project

Jan 25 2019

kpn added a comment to D52839: Inform AST's UnaryOperator of FENV_ACCESS.
Jan 25 2019, 9:40 AM
kpn added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Jan 25 2019, 9:24 AM · Restricted Project

Jan 16 2019

kpn updated the diff for D55897: Add constrained fptrunc and fpext intrinsics.

It was pointed out before I split this ticket out that I wasn't properly passing the correct operand in ExpandNode() when handling the two new STRICT nodes. I've corrected that.

Jan 16 2019, 5:44 AM · Restricted Project

Jan 2 2019

kpn added a comment to D55897: Add constrained fptrunc and fpext intrinsics.

I just realized I missed a couple of changes. Let me work on those and I'll update later.

Jan 2 2019, 9:04 AM · Restricted Project

Dec 19 2018

kpn created D55897: Add constrained fptrunc and fpext intrinsics.
Dec 19 2018, 12:20 PM · Restricted Project

Dec 3 2018

kpn updated the diff for D53157: Teach the IRBuilder about constrained fadd and friends.

Address review comment: Shrink the diff by eliminating unneeded use of else.

Dec 3 2018, 1:14 PM
kpn updated the diff for D53157: Teach the IRBuilder about constrained fadd and friends.

I've changed the patch so that calls to CreateFAdd() et al will give you constrained intrinsics if they are enabled. This required adding functions to enable/disable constrained-as-default plus calls to deal with the rounding mode and exception handling for contrained intrinsics.

Dec 3 2018, 10:51 AM

Nov 21 2018

kpn added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

But given that there is still infrastructure missing in the IR optimizers, I also think that at least in the first implementation, we probably should go with the original approach and just use constrained intrinsics everywhere in the function, and possibly add some function attribute that prevent any cross-inlining of functions built with constrained intrinsics with functions built with regular floating-point operations.

Nov 21 2018, 5:42 AM

Nov 20 2018

kpn added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

If we all agree upon that, then we simply have to treat the functions that modify the FPEnv, e.g. fesetexcept(...), as barriers. That way it does not matter if a FENV_ACCESS=OFF function is translated with constrained intrinsics or not, since nothing can be scheduled around these barriers.

Nov 20 2018, 7:58 AM

Nov 19 2018

kpn added a comment to D53794: [TargetLowering] expandFP_TO_UINT - avoid FPE due to out of range conversion (PR17686).

As I understand the approach, it can never introduce a new trap. Now of course, if the original source value is outside the range of the target integer type, some of the instructions introduced by this approach may trap, but in that case, it is expected for the fp_to_uint operation to trap somewhere.

If the original source value is in range however, then none of the instructions introduced here can ever trap:

	​    // Sel = Src < 0x8000000000000000
	​    // Val = select Sel, Src, Src - 0x8000000000000000
	​    // Ofs = select Sel, 0, 0x8000000000000000
	​    // Result = fp_to_sint(Val) ^ Ofs

The first is a compare that never traps. The select operations themselves also never trap. The first select in addition contains a subtraction, but if Src is in range for the fp_to_uint operation, that subtract cannot trap either. Finally, if Src is in range for fp_to_uint, then by construction the value Val will be in range for fp_to_sint, and therefore that operation cannot trap either.

Nov 19 2018, 7:57 AM

Nov 16 2018

kpn added a comment to D53794: [TargetLowering] expandFP_TO_UINT - avoid FPE due to out of range conversion (PR17686).

Now, the solution suggested in this patch is also interesting since it can be done without introducing new basic blocks (and therefore can be done in SelectionDAG, without needed a new pass). However, in order to generate efficient code we probably still need to get to the same assembler code we'd have gotten from that new pass -- but now instead the burden is on the back-end to recover the if-then-else block from a series of select statements. Not sure what is better here.

Nov 16 2018, 9:41 AM

Nov 8 2018

kpn added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.
In D53157#1291964, @kpn wrote:

I don't expect anyone would need to switch between constrained and regular floating point at an instruction level of granularity.

The Standard allows for this (to some degree). E.g. FENV_ACCESS can be toggled between nested compound statements.

Nov 8 2018, 11:46 AM
kpn added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

Rather than having separate methods to create the constrained versions of the intrinsics, why not have a way to set the constrained state in the IR builder and have the regular CreateFAdd et. al. functions use that to automatically create the constrained intrinsic versions? This would correspond to how fast math flags are handled.

Nov 8 2018, 11:30 AM
kpn updated subscribers of D53157: Teach the IRBuilder about constrained fadd and friends.
Nov 8 2018, 11:27 AM

Nov 7 2018

kpn added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

Adding the usual suspects: @andrew.w.kaylor @craig.topper @uweigand @hfinkel

I don't see the benefit of this change. The intrinsics are good enough to be functional right now (minus a few that are in progress), so I'm not sure we need IRBuilder functions. Am I missing something?

Nov 7 2018, 8:30 AM
kpn added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

Should the builder's FastMathFlags setting apply to these calls? Is it worth adding an optional FMF parameter to these now, so we don't end up with duplicated API like we have for the regular FP binops?

Nov 7 2018, 8:00 AM

Nov 6 2018

kpn updated the diff for D53157: Teach the IRBuilder about constrained fadd and friends.

Update to have tests in this patch.

Nov 6 2018, 12:14 PM
kpn updated the diff for D43515: More math intrinsics for conservative math handling.

Minor test changes.

Nov 6 2018, 12:02 PM
kpn added inline comments to D43515: More math intrinsics for conservative math handling.
Nov 6 2018, 10:29 AM

Nov 5 2018

kpn added inline comments to D43515: More math intrinsics for conservative math handling.
Nov 5 2018, 12:37 PM

Nov 2 2018

kpn added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.

The only thing we need to worry about is making sure that FP operations don't migrate across calls or other FP operations that would break these semantics. Using the intrinsics after inlining takes care of that.

I don't agree with this. This is changing the semantics if we choose to inline a function by converting some operations into constrained intrinsics. In other words, an executable will have different behavior if we choose to inline or not. That's not ok.

Well, yes and no. In a region defined as FENV_ACCESS off the user has granted the compiler explicit permission to ignore FP status bits and exception behavior. Depending on how we optimize these regions the FP status bits may come out differently and exceptions may or may not be raised, but the user has promised not to unmask exceptions or look at status bits in that region. So if that part of the behavior of the code changes depending on whether or not we inline that's OK because that's what the user signed up for. In that sense the behavior hasn't changed any more than it does between -O0 and -O3.

Nov 2 2018, 12:20 PM
kpn added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.
In D43142#1285565, @kpn wrote:

If all optimizations including constant folding, or at least optimizations on floating point, are delayed until after inlining then there's no problem.

I'll add that this is a ton of work. A binary Instruction can't currently have two Constant operands. So, ConstantFolding is baked into the Instruction implementation right now. If I'm mistaken, someone please correct me.

Nov 2 2018, 10:47 AM
kpn added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.
In D43142#1284190, @kpn wrote:

...

It's unclear to me how LTO (or other cross file inlining) would work here. I haven't given it much though until now. My knee-jerk reaction is that we shouldn't be inlining from a FENV_ACCESS=OFF to FENV_ACCESS=ON location.

I'm pretty sure that we decided that we couldn't (because once you inline the regular FP ops, there's no way to restrict their movement relative to the constrained intrinsics at the IR level).

I thought what we said was that if constrained FP intrinsics were used anywhere in a function then they had to be used everywhere in the function. So if you inline a function with FENV_ACCESS=ON into a function with FENV_ACCESS=OFF then the FP operations in the destination function need to be converted to constrained intrinsics, and if you inline a function with FENV_ACCESS=OFF into a function with FENV_ACCESS=ON then the FP operations in the function being inlined need to be converted. This conversion will have a detrimental effect on optimizations, so it would be nice to factor that into the inling cost, but at this point I'm mostly concerned about generating correct code.

Nov 2 2018, 9:34 AM
kpn added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.

I thought what we said was that if constrained FP intrinsics were used anywhere in a function then they had to be used everywhere in the function. So if you inline a function with FENV_ACCESS=ON into a function with FENV_ACCESS=OFF then the FP operations in the destination function need to be converted to constrained intrinsics, and if you inline a function with FENV_ACCESS=OFF into a function with FENV_ACCESS=ON then the FP operations in the function being inlined need to be converted. This conversion will have a detrimental effect on optimizations, so it would be nice to factor that into the inling cost, but at this point I'm mostly concerned about generating correct code.

I'm realizing that FENV_ACCESS is poorly designed.

Let's take this small example:

#include <fenv.h>
#include <stdio.h>

void bar();

#pragma STDC FENV_ACCESS ON
int main() {
  feenableexcept(FE_DIVBYZERO);
  bar();
  float x = 1.0/0.0;
  printf("main x=%lf\n", x);
}

#pragma STDC FENV_ACCESS OFF
void bar() {
  float x = 1.0/0.0;
  printf("bar x=%lf\n", x);
}

The FDiv in bar() would access the FP environment since main() enabled exceptions. But, since bar() is preceded with FENV_ACCESS=OFF, the Standard says that accessing the FP environment in bar() is undefined behavior. Since it's undefined behavior, the compiler can optimize as it wishes, including inlining bar() without modifying the FDiv.

Nov 2 2018, 9:27 AM

Nov 1 2018

kpn added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.
In D43142#1284190, @kpn wrote:

And couldn't we turn off constant folding in the IRBuilder when necessary?

I don't think that would work in all cases. E.g. a binary operator with two constant operands.

int main() {
  float z = 5.0/0.0;
  return z;
}

Well, not without a considerable effort to rework the IRBuilder at least. I'm fairly sure we can't produce an Instruction with two Constant operands right now.

Nov 1 2018, 11:45 AM
kpn added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.

Oh, of course FNeg will need to be emitted by the front end. And couldn't we turn off constant folding in the IRBuilder when necessary?

Nov 1 2018, 10:49 AM
kpn added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.

Isn't this pass needed since we don't have a way to prevent code movement between blocks using the pragma FENV_ACCESS ON and blocks that aren't? I suggest having it check for use of constrained intrinsics before making any changes.

Nov 1 2018, 10:26 AM
kpn updated the diff for D43515: More math intrinsics for conservative math handling.

Address review comments.

Nov 1 2018, 10:19 AM

Oct 31 2018

kpn added a comment to D53932: [NFCI][FPEnv] Split constrained intrinsic tests.

FWIW, I like it.

Oct 31 2018, 7:24 AM

Oct 30 2018

kpn updated subscribers of D53424: Enable thread specific cl::opt values for multi-threaded support.

Personally, I'd like to see something where developer-only debug options show up in -help-hidden or similar for the correct executable: opt vs llc. Right now I'm pretty sure they don't. I don't have any opinion on how to make that happen, though.

Oct 30 2018, 12:44 PM

Oct 19 2018

kpn added a comment to D53411: [FPEnv] Add constrained CEIL/FLOOR/ROUND/TRUNC intrinsics.

While you're at it, shouldn't we also add ROUND and TRUNC to complete the set?

Oct 19 2018, 5:56 AM

Oct 18 2018

kpn added inline comments to D53216: [FPEnv] Add constrained intrinsics for MAXNUM and MINNUM.
Oct 18 2018, 11:25 AM

Oct 12 2018

kpn updated the diff for D52839: Inform AST's UnaryOperator of FENV_ACCESS.

Upload the correct diff this time. Sorry about the confusion!

Oct 12 2018, 11:12 AM
kpn updated the diff for D52839: Inform AST's UnaryOperator of FENV_ACCESS.

Address review comments.

Oct 12 2018, 10:59 AM

Oct 11 2018

kpn added a comment to D52839: Inform AST's UnaryOperator of FENV_ACCESS.

I forgot to address the template question. I've spend the past 18 years doing SystemZ backend work on multiple {,JIT} compilers. I'm not really in a position to answer your question about how to handle getting these FP bits down into C++ templates. I hope that won't hold up getting FENV_ACCESS working for C compilations.

Oct 11 2018, 12:36 PM
kpn added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

The test case for this is in D52839, now.

Oct 11 2018, 12:03 PM
kpn updated the diff for D52839: Inform AST's UnaryOperator of FENV_ACCESS.

Address review comments.

Oct 11 2018, 12:02 PM
kpn created D53157: Teach the IRBuilder about constrained fadd and friends.
Oct 11 2018, 12:00 PM

Oct 9 2018

kpn updated the diff for D51372: FENV_ACCESS support for libm-style constrained intrinsics.

Update based on feedback to D52839: add missing AST (de)serialization support.

Oct 9 2018, 9:08 AM

Oct 4 2018

kpn added inline comments to D43515: More math intrinsics for conservative math handling.
Oct 4 2018, 11:58 AM
kpn added inline comments to D43515: More math intrinsics for conservative math handling.
Oct 4 2018, 10:54 AM
kpn added inline comments to D43515: More math intrinsics for conservative math handling.
Oct 4 2018, 6:42 AM

Oct 3 2018

kpn added a comment to D43515: More math intrinsics for conservative math handling.

Ping

Oct 3 2018, 11:44 AM
kpn created D52839: Inform AST's UnaryOperator of FENV_ACCESS.
Oct 3 2018, 11:43 AM

Sep 18 2018

kpn updated the diff for D51372: FENV_ACCESS support for libm-style constrained intrinsics.

Correct obvious error with powi. Fix test and test both C and (partial) C++.

Sep 18 2018, 10:02 AM

Sep 17 2018

kpn updated the diff for D43515: More math intrinsics for conservative math handling.

Split out changes as requested. This diff is just the four new intrinsics. The fptoui pass and the change to frem will be later.

Sep 17 2018, 9:50 AM

Sep 10 2018

kpn added a comment to D43515: More math intrinsics for conservative math handling.

Adding new constrained instrinsics and adding the pass should be separate patches I think. Changing the syntax of frem should be another patch.

Sep 10 2018, 10:45 AM

Sep 4 2018

kpn updated the diff for D43515: More math intrinsics for conservative math handling.

Rebase. Ping.

Sep 4 2018, 9:17 AM

Aug 28 2018

kpn created D51372: FENV_ACCESS support for libm-style constrained intrinsics.
Aug 28 2018, 11:56 AM

Aug 27 2018

kpn added a comment to D51255: [WWW] Use https instead of http to fix page problems.
In D51255#1214424, @asl wrote:

I think we need to preserve the protocol. E.g. if the page is loaded via http we need to load css via http as well.

That sounds reasonable and is (afaik) implied by removing the hostname.
As mentioned before, I like the solution but I just don't know if that might cause problems somewhere else.

Aug 27 2018, 7:32 AM