Page MenuHomePhabricator

andrew.w.kaylor (Andy Kaylor)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 2 2013, 1:50 PM (367 w, 2 d)

Recent Activity

Yesterday

andrew.w.kaylor added inline comments to D72820: [FPEnv] Add pragma FP_CONTRACT support under strict FP..
Fri, Jan 17, 3:30 PM · Restricted Project, Restricted Project
andrew.w.kaylor added inline comments to D72930: [FEnv] Constfold some unary constrained operations.
Fri, Jan 17, 11:58 AM · Restricted Project
andrew.w.kaylor accepted D69878: Consoldiate internal denormal flushing controls.

I don't know if there were other reviewers who haven't commented on how you addressed their concerns, but this looks good to me.

Fri, Jan 17, 11:30 AM · Restricted Project

Thu, Jan 16

andrew.w.kaylor added a comment to D72871: [FPEnv] Divide macro INSTRUCTION into INSTRUCTION and DAG_INSTRUCTION, and macro FUNCTION likewise. NFCI..

Could you make this a standalone patch that only modifies the table without adding the FP_CONTRACT support? Then the other patch can just be refactored to use this.

Thu, Jan 16, 2:24 PM · Restricted Project
andrew.w.kaylor added inline comments to D72820: [FPEnv] Add pragma FP_CONTRACT support under strict FP..
Thu, Jan 16, 2:15 PM · Restricted Project, Restricted Project
andrew.w.kaylor added inline comments to D69878: Consoldiate internal denormal flushing controls.
Thu, Jan 16, 1:45 PM · Restricted Project
andrew.w.kaylor added inline comments to D72820: [FPEnv] Add pragma FP_CONTRACT support under strict FP..
Thu, Jan 16, 12:08 PM · Restricted Project, Restricted Project

Fri, Jan 10

andrew.w.kaylor created D72540: [WinEH] Ignore lifetime.end PHI nodes in empty cleanuppads.
Fri, Jan 10, 2:06 PM · Restricted Project
andrew.w.kaylor added inline comments to D69878: Consoldiate internal denormal flushing controls.
Fri, Jan 10, 11:09 AM · Restricted Project

Thu, Jan 9

andrew.w.kaylor added inline comments to D69878: Consoldiate internal denormal flushing controls.
Thu, Jan 9, 6:44 PM · Restricted Project

Wed, Jan 8

andrew.w.kaylor added a comment to D72425: [OptRemark] RFC: Introduce a message table for OptRemarks.

As Francis mentioned it before it would be good derive the pass name from the remark type (diag::remark_gvn_load_elim -> gvn) . I.e. I would drop the DEBUG_TYPE argument.

Wed, Jan 8, 5:10 PM · Restricted Project
andrew.w.kaylor added a comment to D72425: [OptRemark] RFC: Introduce a message table for OptRemarks.

I like this general idea; couple of thoughts...

  1. Clang has a similar system, and one disadvantage is that any time you change/add any message, it seems to trigger a large rebuild. Could we have this TG system generate separate .inc files for each category of things, so we don't have the same kind of rebuild problem.
Wed, Jan 8, 5:01 PM · Restricted Project
andrew.w.kaylor created D72425: [OptRemark] RFC: Introduce a message table for OptRemarks.
Wed, Jan 8, 4:05 PM · Restricted Project

Mon, Jan 6

andrew.w.kaylor added inline comments to D69878: Consoldiate internal denormal flushing controls.
Mon, Jan 6, 11:13 AM · Restricted Project
andrew.w.kaylor added inline comments to D69878: Consoldiate internal denormal flushing controls.
Mon, Jan 6, 10:06 AM · Restricted Project

Fri, Jan 3

andrew.w.kaylor accepted D72193: [LegalizeTypes] Add widening support for STRICT_FSETCC/FSETCCS.

lgtm

Fri, Jan 3, 6:31 PM · Restricted Project

Mon, Dec 23

andrew.w.kaylor added inline comments to D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.
Mon, Dec 23, 1:40 PM · Restricted Project
andrew.w.kaylor added inline comments to D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.
Mon, Dec 23, 1:22 PM · Restricted Project

Dec 18 2019

andrew.w.kaylor added a comment to D71635: [clang] Rename -frounding-math to -fexperimental-rounding-math and add -frounding-math back as a gcc-compat arg..

Before:

% clang -frounding-math -fsyntax-only -x c /dev/null
clang-10: warning: Support for floating point control option frounding-math is incomplete and experimental [-Wexperimental-float-control]

CC1 will do rounding math things.

After

% clang -frounding-math -fsyntax-only -x c /dev/null
clang-10: warning: optimization flag '-frounding-math' is not supported [-Wignored-optimization-argument]

CC1 will not do rounding math things. -fexperimental-rounding-math if the user really wants to use the feature.

Is my understanding correct? If yes, this patch seems pretty reasonable to me, because -frounding-math is currently incomplete/unsafe.

You may consider not changing CC1 options as they are not user facing.

Dec 18 2019, 5:40 PM · Restricted Project

Dec 17 2019

andrew.w.kaylor added a comment to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.

It seems the discussion of whether or not this is incomplete died out -- I'd prefer to assume it is incomplete if there is no consensus. Mailed D71635 to rename -frounding-math to -fexperimental-rounding-math.

Alternatively we could remove the warning. I still don't see a good argument for the middle ground of having it called -frounding-math but also generate a warning.

Dec 17 2019, 4:59 PM · Restricted Project, Restricted Project

Dec 13 2019

andrew.w.kaylor added a comment to D71238: Align non-fused branches within 32-Byte boundary (basic case).

I'm late jumping into the discussion of these patches and may not have seen all comments, so go easy on me if I say something that has already been covered.

Dec 13 2019, 5:25 PM · Restricted Project
andrew.w.kaylor added inline comments to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.
Dec 13 2019, 4:13 PM · Restricted Project, Restricted Project
andrew.w.kaylor added a comment to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.

... The big problem is that intrinsic calls are not arbitrary code: the vast majority of intrinsics (e.g. all the ARM vector intrinsics, many of which can be floating-point) are marked IntrNoMem (which I believe corresponds to readnone), which means calls to those intrinsics can be reordered with other code whether or not that code has arbitrary side-effects.

Dec 13 2019, 4:13 PM · Restricted Project, Restricted Project
andrew.w.kaylor added a comment to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.

Hmm. The target-specific intrinsics thing does concern me, since I assume many targets have a bunch of vector intrinsics that may be sensitive to rounding. Do we have an idea of how we'd fix that? If it's a short-term incorrectness that we have a plan to fix, I don't mind the risk, but if we don't know how we'd even start to address it...

Dec 13 2019, 1:09 PM · Restricted Project, Restricted Project

Dec 12 2019

andrew.w.kaylor added a comment to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.

Currently we emit a warning if you use -frounding-math, saying that the option is ignored. That should have alerted users that they're not getting the correct behavior now. This patch removes the warning and (IIUC) implements the correct behavior but is over-conservative. If that's correct, I think that's acceptable and we don't need an "experimental" flag or a warning.

Dec 12 2019, 5:37 PM · Restricted Project, Restricted Project
andrew.w.kaylor added inline comments to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.
Dec 12 2019, 1:31 PM · Restricted Project, Restricted Project

Dec 11 2019

andrew.w.kaylor added a comment to D59780: Support Intel Control-flow Enforcement Technology.

Hmm, I'm sorry but I'm confused. IIRC I had a discussion in the LLVM dev meeting that we were going to submit a change with a single PLT scheme rather than IPLT, so when I said that I'm going to submit a patch, I meant that I'm going to submit a patch for the 1PLT scheme rather than the 2PLT scheme. But this is for the 2PLT scheme. This is not something I want.

What was the decision that was made at the developer meeting? Will lld support the 2PLT scheme defined in the psABI?

Dec 11 2019, 7:58 AM · Restricted Project

Dec 4 2019

andrew.w.kaylor added a comment to D67105: [TargetLowering] Fix another potential FPE in expandFP_TO_UINT.

I'm afraid we may have made a mess of this for X86 in D70214. We noticed the problem that you're fixing here, but I didn't realize you had a solution for it. I guess I hadn't looked at this patch. I'm sorry about that. Your solution looks good to me.

Dec 4 2019, 12:26 PM · Restricted Project
andrew.w.kaylor abandoned D57970: [WinEH] Allocate unique stack slots for xmm CSRs in funclets.

This was fixed in a different way.

Dec 4 2019, 12:06 PM · Restricted Project
andrew.w.kaylor added a comment to D65921: [X86] Add DSB subtarget feature. NFC.

Can this patch be abandoned?

Dec 4 2019, 11:59 AM · Restricted Project
andrew.w.kaylor abandoned D70261: [strictfp] Add token support for FP constraints.

I think we've agreed that this isn't a good use of tokens. The operand bundle approach may still be useful, but that can be attempted in a new revision.

Dec 4 2019, 11:59 AM · Restricted Project

Nov 27 2019

andrew.w.kaylor added a comment to D69281: [FPEnv] Constrained FCmp intrinsics.

To clarify, I was suggesting a single intrinsic with quiet/signaling encoded in the predicate. I think the IR definition is a bit cleaner this way and it maps to both the IEEE specification and at least the most common way (I think) this is implemented in x86 hardware and probably others. That said, if doing it this way makes the implementation more complicated I could go along with separate intrinsics and ISD opcodes.

Nov 27 2019, 11:42 AM · Restricted Project

Nov 26 2019

andrew.w.kaylor added inline comments to D69281: [FPEnv] Constrained FCmp intrinsics.
Nov 26 2019, 11:35 AM · Restricted Project

Nov 25 2019

andrew.w.kaylor added a comment to D69281: [FPEnv] Constrained FCmp intrinsics.

I would prefer a single intrinsic/opcode with additional predicates to handle signalling vs. quiet. My main reason is consistency with how the IEEE-754 spec describes comparisons, but that's a weak argument. @craig.topper mentioned to me that there are some additional opcodes that might need to be duplicated if you treat signalling and quiet as separate operations.

Nov 25 2019, 2:37 PM · Restricted Project

Nov 20 2019

andrew.w.kaylor added inline comments to D70451: [FPEnv] IRBuilder should not put strictfp on function definitions automatically.
Nov 20 2019, 3:01 PM · Restricted Project

Nov 19 2019

andrew.w.kaylor accepted D70220: [LegalizeDAG][X86] Enable STRICT_FP_TO_SINT/UINT to be promoted.

lgtm

Nov 19 2019, 3:56 PM · Restricted Project
andrew.w.kaylor accepted D70214: [X86] Add custom type legalization and lowering for scalar STRICT_FP_TO_SINT/UINT.

lgtm

Nov 19 2019, 3:46 PM · Restricted Project
andrew.w.kaylor added inline comments to D70451: [FPEnv] IRBuilder should not put strictfp on function definitions automatically.
Nov 19 2019, 3:27 PM · Restricted Project
andrew.w.kaylor added inline comments to D70451: [FPEnv] IRBuilder should not put strictfp on function definitions automatically.
Nov 19 2019, 2:33 PM · Restricted Project
andrew.w.kaylor added inline comments to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.
Nov 19 2019, 12:24 PM · Restricted Project, Restricted Project
andrew.w.kaylor added inline comments to D70451: [FPEnv] IRBuilder should not put strictfp on function definitions automatically.
Nov 19 2019, 12:15 PM · Restricted Project

Nov 15 2019

andrew.w.kaylor added inline comments to D70214: [X86] Add custom type legalization and lowering for scalar STRICT_FP_TO_SINT/UINT.
Nov 15 2019, 5:27 PM · Restricted Project
andrew.w.kaylor added a comment to D70261: [strictfp] Add token support for FP constraints.

As referenced in Simon's reply, I have started a mailing list discussion about this.

Nov 15 2019, 1:04 PM · Restricted Project

Nov 14 2019

andrew.w.kaylor added inline comments to D70214: [X86] Add custom type legalization and lowering for scalar STRICT_FP_TO_SINT/UINT.
Nov 14 2019, 2:55 PM · Restricted Project
andrew.w.kaylor accepted D69552: Move floating point related entities to namespace level.

This looks good to me. I like the header file name and location you have here.

Nov 14 2019, 11:57 AM · Restricted Project, Restricted Project
andrew.w.kaylor added a reviewer for D70261: [strictfp] Add token support for FP constraints: simoll.
Nov 14 2019, 11:20 AM · Restricted Project
andrew.w.kaylor added inline comments to D69281: [FPEnv] Constrained FCmp intrinsics.
Nov 14 2019, 11:20 AM · Restricted Project
andrew.w.kaylor created D70261: [strictfp] Add token support for FP constraints.
Nov 14 2019, 11:11 AM · Restricted Project

Nov 13 2019

andrew.w.kaylor added inline comments to D69281: [FPEnv] Constrained FCmp intrinsics.
Nov 13 2019, 11:04 AM · Restricted Project

Nov 12 2019

andrew.w.kaylor added inline comments to D69978: Separately track input and output denormal mode.
Nov 12 2019, 5:59 PM · Restricted Project
andrew.w.kaylor added inline comments to D69281: [FPEnv] Constrained FCmp intrinsics.
Nov 12 2019, 1:16 PM · Restricted Project
andrew.w.kaylor accepted D69598: Work on cleaning up denormal mode handling.

Thanks. I understand your direction for denormal handling now, and I'm OK with this patch apart from the remaining references to subnormal that Sanjay mentioned.

Nov 12 2019, 12:10 PM · Restricted Project

Nov 11 2019

andrew.w.kaylor added inline comments to D69798: Implement inlining of strictfp functions.
Nov 11 2019, 3:50 PM · Restricted Project
andrew.w.kaylor added inline comments to D69275: Add constrained int->FP intrinsics.
Nov 11 2019, 2:11 PM · Restricted Project
andrew.w.kaylor added a comment to D70096: [strictfp] Replace dangling strictfp attrs with nobuiltin.
In D70096#1741213, @kpn wrote:

Do we want to restrict this so it doesn't get upgraded if found in a future bitcode version?

Nov 11 2019, 12:58 PM · Restricted Project
andrew.w.kaylor added a comment to D70096: [strictfp] Replace dangling strictfp attrs with nobuiltin.

@pcc I've added you as a reviewer in hopes that you can tell me whether my use of code in globalCleanup() is correct. It seems to be working, but Craig was concerned that there might be cases under which this would be called when things weren't sufficiently materialized to properly handle the distinction between function declaration and definition.

Nov 11 2019, 11:53 AM · Restricted Project
andrew.w.kaylor created D70096: [strictfp] Replace dangling strictfp attrs with nobuiltin.
Nov 11 2019, 11:45 AM · Restricted Project

Nov 8 2019

andrew.w.kaylor added a comment to D69598: Work on cleaning up denormal mode handling.

I'm unclear as to the expectations surrounding this option. I suppose this is somewhat beyond the scope of the current changes, but I'm confused by clang's current behavior with regard to denormals.

Nov 8 2019, 5:44 PM · Restricted Project

Nov 5 2019

andrew.w.kaylor added a comment to D69552: Move floating point related entities to namespace level.

I like this. I have just one minor suggestion.

Nov 5 2019, 12:20 PM · Restricted Project, Restricted Project

Nov 4 2019

andrew.w.kaylor added a comment to D69281: [FPEnv] Constrained FCmp intrinsics.

This looks like a very good start. I've talked to @pengfei about the x86 backend support for this. As long as x86 doesn't fail horribly, I'd be OK with the x86 work being done in a separate patch that depends on this one.

Nov 4 2019, 5:42 PM · Restricted Project
andrew.w.kaylor added inline comments to D69798: Implement inlining of strictfp functions.
Nov 4 2019, 3:12 PM · Restricted Project

Oct 29 2019

andrew.w.kaylor added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.
    1. Observations
  • When using fpexcept.ignore, the fp callsites should have the readnone attribute set on them to override the inaccessiblememonly of the intrinsic declarations. That way DCE still works.
Oct 29 2019, 5:34 PM · Restricted Project

Oct 21 2019

andrew.w.kaylor added a comment to D69272: Enable '#pragma STDC FENV_ACCESS' in frontend.

Thanks for the patch! I don't have time to review this in detail this week, but I'm very happy to see this functionality.

Oct 21 2019, 1:54 PM · Restricted Project

Oct 9 2019

andrew.w.kaylor added a comment to D68686: [X86] Model MXCSR for [v]add|sub|mul|div* instructions.

This patch seems to be doing at least two different things. Can you separate the changes related to strict node handling into a separate patch?

Oct 9 2019, 2:52 PM · Restricted Project

Oct 3 2019

andrew.w.kaylor added a comment to D64746: Add constrained intrinsics for lrint and lround.

This looks good to me, but I'd like @craig.topper to verfiy that he's happy with the parts he commented on.

Oct 3 2019, 1:23 PM · Restricted Project
andrew.w.kaylor accepted D67925: [FPEnv] Strict FP tests should use the requisite function attributes.

I assume you've tested this with your verifier changes. This is a bit too much to verify every call and function manually. I looked at the ones that weren't boilerplate updates, and I sampled the boilerplate changes. Based on that review strategy, it looks good to me.

Oct 3 2019, 1:21 PM · Restricted Project

Sep 25 2019

andrew.w.kaylor updated subscribers of D67839: [FPEnv] Document requirement of function attributes with constrained floating point.
In D67839#1683038, @kpn wrote:

I agree with marking function call sites as "strictfp".

Say, would this apply to all function call sites? Or just to ones that aren't intrinsics?

Sep 25 2019, 12:16 PM · Restricted Project
andrew.w.kaylor accepted D67839: [FPEnv] Document requirement of function attributes with constrained floating point.

This looks good to me.

Sep 25 2019, 11:58 AM · Restricted Project

Sep 24 2019

andrew.w.kaylor added a comment to D67839: [FPEnv] Document requirement of function attributes with constrained floating point.

It was probably me that argued for the strictfp attribute being required on the function definition. My reasoning was that when the inliner wants to inline a function containing strict FP calls into a function that does not, it would use the strictfp attribute as a cue to convert all of the FP operations in the target function to constrained. This can, of course, be deduced from the IR, but if we treat the attribute on the definition as optional then the inliner would always need to check the IR anyway. So if it isn't required it has limited usefulness.

Sep 24 2019, 1:49 PM · Restricted Project

Sep 17 2019

andrew.w.kaylor reopened D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.

Need to fix Sphinx warnings

Sep 17 2019, 3:11 PM · Restricted Project

Sep 16 2019

andrew.w.kaylor added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 16 2019, 5:13 PM · Restricted Project

Sep 13 2019

andrew.w.kaylor added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 13 2019, 3:29 PM · Restricted Project
andrew.w.kaylor added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 13 2019, 2:40 PM · Restricted Project
andrew.w.kaylor added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 13 2019, 1:10 PM · Restricted Project
andrew.w.kaylor accepted D67360: [FPEnv] Document that constrained FP intrinsics cannot be mixed with non-constrained.

Thanks for updating this bit of documentation!

Sep 13 2019, 12:24 PM · Restricted Project

Sep 12 2019

andrew.w.kaylor added inline comments to D67360: [FPEnv] Document that constrained FP intrinsics cannot be mixed with non-constrained.
Sep 12 2019, 5:14 PM · Restricted Project
andrew.w.kaylor added a comment to D67360: [FPEnv] Document that constrained FP intrinsics cannot be mixed with non-constrained.
In D67360#1668007, @kpn wrote:

Address review comment. Mention the possibility of the restrictions mentioned here changing in the future, but don't make any promises.

Sep 12 2019, 4:55 PM · Restricted Project

Aug 27 2019

andrew.w.kaylor added inline comments to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.
Aug 27 2019, 12:09 PM · Restricted Project, Restricted Project
andrew.w.kaylor added inline comments to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.
Aug 27 2019, 11:40 AM · Restricted Project, Restricted Project

Aug 16 2019

andrew.w.kaylor added inline comments to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.
Aug 16 2019, 6:45 PM · Restricted Project, Restricted Project
andrew.w.kaylor added a comment to D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions.

It took some digging, but I finally found the e-mail thread where we initially agreed that we can't mix constrained FP intrinsics and non-constrained FP operations within a function. Here it is: http://lists.llvm.org/pipermail/cfe-dev/2017-August/055325.html

Aug 16 2019, 3:58 PM · Restricted Project
andrew.w.kaylor added a comment to D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions.
  • What is the issue with moving a = b/c? If it moves ahead of if statement it seems OK, because the rounding mode is the same in that point. It cannot be moved inside the block (where rounding mode is different) because it breaks semantics.
Aug 16 2019, 3:23 PM · Restricted Project
andrew.w.kaylor added inline comments to D65997: Add options rounding and exceptions to pragma fp.
Aug 16 2019, 3:14 PM · Restricted Project

Aug 15 2019

andrew.w.kaylor added a comment to D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions.

Replacement of floating point operations with constrained intrinsics seems more an optimization helper then a semantic requirement. IR where constrained operations are mixed with unconstrained is still valid in sense of IR specification.

Aug 15 2019, 2:42 PM · Restricted Project
andrew.w.kaylor added inline comments to D65997: Add options rounding and exceptions to pragma fp.
Aug 15 2019, 1:30 PM · Restricted Project

Aug 14 2019

andrew.w.kaylor added a comment to D66092: [CodeGen] Generate constrained fp intrinsics depending on FPOptions.
In D66092#1625380, @kpn wrote:

Also, if any constrained intrinsics are used in a function then the entire function needs to be constrained. Is this handled anywhere?

If we decided to make the entire function constrained, it should be done somewhere in IR transformations, because inlining may mix function bodies with different fp options.

Aug 14 2019, 8:56 AM · Restricted Project

Aug 9 2019

andrew.w.kaylor added a comment to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.

@andrew.w.kaylor Thanks Andy. Reminder -- in a private document you indicated to me that -fp-speculation=safe corresponds to the maytrap setting for the exception argument. This patch is implemented with those semantics.

Aug 9 2019, 9:00 AM · Restricted Project, Restricted Project

Aug 7 2019

andrew.w.kaylor added a comment to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.

I'm not entirely caught up on this review. I've only read the most recent comments, but I think I've got enough context to comment on the metadata arguments.

Aug 7 2019, 6:02 PM · Restricted Project, Restricted Project

Jul 15 2019

andrew.w.kaylor added inline comments to D64746: Add constrained intrinsics for lrint and lround.
Jul 15 2019, 2:54 PM · Restricted Project
andrew.w.kaylor added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

My understanding is that IEEE-754 requires us to produce an exception if and only if the exception would be produced by a literal interpretation of the source. However, it does not require that the exceptions be raised in the same order as implied by the source. Also, that's what the LLVM language reference says we'll do with "fpexcept.strict" -- "The number and order of floating-point exceptions is NOT guaranteed." So, I think the changes you've got here are correct.

Jul 15 2019, 1:36 PM · Restricted Project

Jul 3 2019

andrew.w.kaylor added a comment to D64067: [X86][PPC] Support -mlong-double-64.

One thing to realize about these flags is that they're ABI-altering flags. If the user provides the flag to alter the platform defaults, this only works if the user also ensures that matches the ABI of the relevant system libraries that the compiler is using (e.g., because the user is explicitly linking with a suitable libc).

Jul 3 2019, 11:34 AM · Restricted Project, Restricted Project
andrew.w.kaylor added a comment to D64067: [X86][PPC] Support -mlong-double-64.

In this review (https://reviews.llvm.org/D6260) @rsmith mentions that this should also have an effect on name mangling.

Jul 3 2019, 8:25 AM · Restricted Project, Restricted Project

Jun 27 2019

andrew.w.kaylor added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

I might be opening a can of worms here and I'm not a language expert, but it isn't clear to me from reading the C99 standard that defining fptosi/fptoui as returning poison values in the unrepresentable case allows correct implementation of the C standard. That is, it doesn't seem to me that the standard actually says this is undefined behavior. It just says the resulting value is unspecified, and the exception behavior is explicitly defined. On the other hand, C++ does say clearly that it is undefined behavior, right?

Jun 27 2019, 3:52 PM · Restricted Project
andrew.w.kaylor added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

For the constrained intrinsics, at least in the case where the exception semantics argument is "fpexcept.strict", we need to make sure the invalid exception is raised. If the exception semantics argument is "fpexcept.ignore" or "fpexcept.maytrap" we could allow the conversion to be optimized away.

Jun 27 2019, 12:29 PM · Restricted Project

Jun 18 2019

andrew.w.kaylor added a comment to D43515: More math intrinsics for conservative math handling.
In D43515#1548845, @kpn wrote:

I believe the speculative exceptions should be largely fixed by r348251, committed by rksimon. I changed the code to continue to use strict nodes when expanding a strict node. Since the strict nodes are chained, does that not solve the part of the problem not solved by r348251? Is the existing comment not enough, or do I need to copy some of the commit message into code comments?

Jun 18 2019, 12:49 PM

Jun 17 2019

andrew.w.kaylor added a comment to D43515: More math intrinsics for conservative math handling.

How would you feel about rebooting this as a new patch? There's a lot of irrelevant history here, and I feel like I'm missing some context as I review it.

Jun 17 2019, 3:06 PM

Jun 4 2019

andrew.w.kaylor accepted D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

OK. I'm convinced. This should let us get a correct solution in place, and as you say we can add on something to handle rounding modes later if needed.

Jun 4 2019, 2:13 PM · Restricted Project

Jun 3 2019

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

Why is the FPBarrierChain getting involved with the BarrierChain for memory objects? Even without this patch I think we might be entangling the strict FP nodes with other chained nodes more than we should.

The BarrierChain tracks calls, volatile/atomic memory accesses, and UnmodeledSideEffects. I do believe that FP exceptions must indeed be kept stable relative to those.

My patch does *not* entangle FP exceptions with regular memory accesses, which do *not* touch BarrierChain.

Jun 3 2019, 2:57 PM · Restricted Project
andrew.w.kaylor committed rG4172dbab5dd3: Fix a crash when the default of a switch is removed (authored by andrew.w.kaylor).
Fix a crash when the default of a switch is removed
Jun 3 2019, 10:55 AM
andrew.w.kaylor added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

Why is the FPBarrierChain getting involved with the BarrierChain for memory objects? Even without this patch I think we might be entangling the strict FP nodes with other chained nodes more than we should.

Jun 3 2019, 9:21 AM · Restricted Project