Page MenuHomePhabricator

cameron.mcinally (Cameron McInally)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 6 2015, 6:21 AM (249 w, 2 d)

Recent Activity

Mon, Oct 14

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Both the ASan build:

Mon, Oct 14, 3:00 PM · Restricted Project, Restricted Project
cameron.mcinally committed rG6362a2168bb7: [ASan] Fix IRTests/InstructionsTest.UnaryOperator (authored by cameron.mcinally).
[ASan] Fix IRTests/InstructionsTest.UnaryOperator
Mon, Oct 14, 12:18 PM
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Fix incoming. Sorry for not running the ASan tests...

Mon, Oct 14, 11:11 AM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Apologies, @pcc. Looking now. Will revert if it's not obvious...

Mon, Oct 14, 10:52 AM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Recommitted this patch with Ocaml test fix. I was not able to find quick-start documentation for the Ocaml bindings, so the Ocaml failure has not been tested. That said, the failure mode seems extremely low risk. Will monitor the buildbots for problems...

Mon, Oct 14, 8:43 AM · Restricted Project, Restricted Project
cameron.mcinally committed rG20b8ed2c2b10: [IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator (authored by cameron.mcinally).
[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator
Mon, Oct 14, 8:34 AM

Thu, Oct 10

cameron.mcinally updated subscribers of D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

@gribozavr I see that you also reverted @RKSimon's commit for the OCaml/core.ml failure:

Thu, Oct 10, 11:59 AM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

I reverted it in r374354. Please test before re-landing.

Hmm, how do I run those tests? I did not see that failure with check-all.

That's a pretty straightforward failure. It's just a one-line IR change:

fsub float {{.*}}0{{.*}}, %F1 -> fneg float %F1

Thu, Oct 10, 8:12 AM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

I reverted it in r374354. Please test before re-landing.

Thu, Oct 10, 7:25 AM · Restricted Project, Restricted Project

Wed, Oct 9

cameron.mcinally accepted D68748: Add FMF to vector ops for phi.
Wed, Oct 9, 7:45 PM · Restricted Project
cameron.mcinally committed rG47363a148f1d: [IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator (authored by cameron.mcinally).
[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator
Wed, Oct 9, 2:55 PM
cameron.mcinally closed D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.
Wed, Oct 9, 2:55 PM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D68686: [X86] Model MXCSR for [v]add|sub|mul|div* instructions.

This looks good to me, but other users should review it as well...

Wed, Oct 9, 7:58 AM · Restricted Project

Tue, Oct 8

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Sorry for the slow response. I've been busy with other projects.

Tue, Oct 8, 1:14 PM · Restricted Project, Restricted Project
cameron.mcinally added inline comments to D68203: [SelectionDAG][SVE] Add ISD node for VSCALE..
Tue, Oct 8, 12:22 PM
cameron.mcinally added a comment to D68202: [LLVM IR] Add `vscale` as a symbolic constant..

Looks pretty good. This could probably use some tests in TypeAndConstantValueParsing of llvm/unittests/AsmParser/AsmParserTest.cpp. In particular, an isa<VScale>(...) test would be good. And maybe a negative test to make sure something like <undef x 2 x f64> can't be parsed.

Tue, Oct 8, 12:12 PM
cameron.mcinally added a comment to D68203: [SelectionDAG][SVE] Add ISD node for VSCALE..

What happens if we see IR like:

Tue, Oct 8, 11:44 AM
cameron.mcinally accepted D67749: [AArch64] Stackframe accesses to SVE objects..

LGTM with a moderate confidence level. Maybe give other reviewers a day or so to comment before committing.

Tue, Oct 8, 8:26 AM · Restricted Project

Mon, Oct 7

cameron.mcinally committed rG60786f914392: [llvm-c] Add UnaryOperator to LLVM_FOR_EACH_VALUE_SUBCLASS macro (authored by cameron.mcinally).
[llvm-c] Add UnaryOperator to LLVM_FOR_EACH_VALUE_SUBCLASS macro
Mon, Oct 7, 10:21 PM
cameron.mcinally committed rG46d317fad462: [Bitcode] Update naming of UNOP_NEG to UNOP_FNEG (authored by cameron.mcinally).
[Bitcode] Update naming of UNOP_NEG to UNOP_FNEG
Mon, Oct 7, 10:19 PM
cameron.mcinally created D68588: [Bitcode] Update naming of UNOP_NEG to UNOP_FNEG.
Mon, Oct 7, 1:02 PM · Restricted Project
cameron.mcinally added inline comments to D67749: [AArch64] Stackframe accesses to SVE objects..
Mon, Oct 7, 12:41 PM · Restricted Project
cameron.mcinally added inline comments to D53877: [IR] Strawman for dedicated FNeg IR instruction.
Mon, Oct 7, 9:05 AM · Restricted Project
cameron.mcinally added inline comments to D53877: [IR] Strawman for dedicated FNeg IR instruction.
Mon, Oct 7, 8:25 AM · Restricted Project
cameron.mcinally added inline comments to D67749: [AArch64] Stackframe accesses to SVE objects..
Mon, Oct 7, 7:34 AM · Restricted Project

Tue, Oct 1

cameron.mcinally added inline comments to D68265: [InstCombine] Simplify fma multiplication to nan for undef or nan operands..
Tue, Oct 1, 2:51 PM · Restricted Project
cameron.mcinally added inline comments to D68265: [InstCombine] Simplify fma multiplication to nan for undef or nan operands..
Tue, Oct 1, 2:02 PM · Restricted Project
cameron.mcinally accepted D68265: [InstCombine] Simplify fma multiplication to nan for undef or nan operands..

LGTM

Tue, Oct 1, 8:56 AM · Restricted Project

Tue, Sep 24

cameron.mcinally added a comment to D67925: [FPEnv] Strict FP tests should use the requisite function attributes.

Would it be better to do an attributes #0 = { ...} style change? E.g.:

Tue, Sep 24, 11:52 AM · Restricted Project

Sep 17 2019

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

For posterity's sake, @andrew.w.kaylor just suggested adding a nftz fast math flag:

Sep 17 2019, 8:43 AM · Restricted Project, Restricted Project

Sep 16 2019

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Some data points...

Sep 16 2019, 4:34 PM · Restricted Project, Restricted Project
cameron.mcinally updated the diff for D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Address review by @lenary.

Sep 16 2019, 2:17 PM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Someone could argue, though, to just use a constrained strict FSub if you care about DAZ/FTZ. That seems like a valid solution. But, that is really treating DAZ/FTZ like a rounding-mode, not underflow. It would be a heavy hammer to enforce all the side-effect concerns when the user really only cares about DAZ/FTZ. In other words, we'll be losing significant performance in an attempt to gain significant performance.

Sep 16 2019, 1:33 PM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

And I think the case where a user changes MXCSR bits is UB for C/C++ ( https://bugs.llvm.org/show_bug.cgi?id=8100#c15 ). So x86 never has a problem in theory, but it might in practice because users believe that twiddling MXCSR bits is allowed?

Sep 16 2019, 1:10 PM · Restricted Project, Restricted Project
cameron.mcinally accepted D67564: [IR] allow fast-math-flags on phi of FP values.

My confidence is somewhat low though...

Sep 16 2019, 8:26 AM · Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

On 2nd thought, that doesn't really make sense for CSE. The real question is whether we should canonicalize the binary fneg to unary fneg in instcombine. And should that happen before/after/concurrent with this change to clang?

Sep 16 2019, 6:49 AM · Restricted Project, Restricted Project

Sep 13 2019

cameron.mcinally added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 13 2019, 4:29 PM · Restricted Project
cameron.mcinally added a comment to D67564: [IR] allow fast-math-flags on phi of FP values.

Maybe a dumb question, but what happens if two incoming PHI values have different FMFs set? Does the PHI's FMF override those? If so, is that safe?

Sep 13 2019, 2:32 PM · Restricted Project
cameron.mcinally added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 13 2019, 1:38 PM · Restricted Project
cameron.mcinally added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 13 2019, 1:22 PM · Restricted Project
cameron.mcinally added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 13 2019, 7:38 AM · Restricted Project

Sep 12 2019

cameron.mcinally added inline comments to D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'.
Sep 12 2019, 1:48 PM · Restricted Project
cameron.mcinally added a comment to D67360: [FPEnv] Document that constrained FP intrinsics cannot be mixed with non-constrained.

My understanding was that this is a temporary restriction; in the end, the goal is to allow mixing constrained an non-constrained operations, once we have the necessary barriers. Did I misunderstand this?

Sep 12 2019, 12:14 PM · Restricted Project
cameron.mcinally added inline comments to D67446: [ConstProp] allow folding for fma that produces NaN.
Sep 12 2019, 7:13 AM · Restricted Project

Sep 11 2019

cameron.mcinally added inline comments to D67446: [ConstProp] allow folding for fma that produces NaN.
Sep 11 2019, 11:13 AM · Restricted Project
cameron.mcinally added inline comments to D67446: [ConstProp] allow folding for fma that produces NaN.
Sep 11 2019, 10:01 AM · Restricted Project
cameron.mcinally accepted D67446: [ConstProp] allow folding for fma that produces NaN.
Sep 11 2019, 8:07 AM · Restricted Project
cameron.mcinally updated subscribers of D67446: [ConstProp] allow folding for fma that produces NaN.
Sep 11 2019, 8:07 AM · Restricted Project

Sep 9 2019

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

I've been digging through this pass and it seems to be ok AFAICT. OptimizeInst(...) canonicalizes both unary and binary FNegs to -1.0*X, if they are fast and part of a special multiply tree. Other FNegs end up as leaf nodes, so no problem there.

Sep 9 2019, 12:56 PM · Restricted Project, Restricted Project

Aug 28 2019

cameron.mcinally accepted D66871: [SVE] MVT scalable size queries.

LGTM

Aug 28 2019, 7:44 AM · Restricted Project

Aug 26 2019

cameron.mcinally accepted D66755: [DAGCombiner] cancel fnegs from multiplied operands of FMA.

LGTM.

Aug 26 2019, 1:27 PM · Restricted Project

Aug 23 2019

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Given that we may still want the binary fneg generated in Reassociate.cpp, this may be enough then, plus what was done in D66612.

Aug 23 2019, 1:50 PM · Restricted Project, Restricted Project
cameron.mcinally committed rG688f3bc240d0: [Reassoc] Small fix to support unary FNeg in NegateValue(...) (authored by cameron.mcinally).
[Reassoc] Small fix to support unary FNeg in NegateValue(...)
Aug 23 2019, 8:52 AM

Aug 22 2019

cameron.mcinally added a comment to D66612: [Reassoc] Small fix to support unary FNeg in NegateValue(...).

BTW, general comment: Many of the remaining BinaryOperator contexts in Reassociate.cpp will need re-examaination too as UnaryOperator may also be present in places where it currently is not.

Aug 22 2019, 1:29 PM · Restricted Project
cameron.mcinally added inline comments to D66612: [Reassoc] Small fix to support unary FNeg in NegateValue(...).
Aug 22 2019, 1:25 PM · Restricted Project
cameron.mcinally created D66612: [Reassoc] Small fix to support unary FNeg in NegateValue(...).
Aug 22 2019, 11:49 AM · Restricted Project

Aug 20 2019

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

@mcberg2017 Do you have a test you can share?

Aug 20 2019, 7:00 AM · Restricted Project, Restricted Project

Aug 14 2019

cameron.mcinally updated the diff for D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Updated patch to generate unary FNeg in Clang.

Aug 14 2019, 3:08 PM · Restricted Project, Restricted Project

Aug 9 2019

cameron.mcinally accepted D66016: [DAGCombiner] exclude x*2.0 from normal negation profitability rules.

LGTM. Less invasive is good.

Aug 9 2019, 11:26 AM · Restricted Project

Aug 8 2019

cameron.mcinally committed rG8416f20f2f55: [LICM] Support unary FNeg in LICM (authored by cameron.mcinally).
[LICM] Support unary FNeg in LICM
Aug 8 2019, 2:39 PM

Aug 7 2019

cameron.mcinally edited reviewers for D65908: Support unary FNeg in LICM, added: craig.topper; removed: craig.scott.
Aug 7 2019, 2:39 PM · Restricted Project
cameron.mcinally created D65908: Support unary FNeg in LICM.
Aug 7 2019, 2:38 PM · Restricted Project
cameron.mcinally committed rG0091621e0c45: [NFC][LICM] Pre-commit test for unary FNeg support in LICM. (authored by cameron.mcinally).
[NFC][LICM] Pre-commit test for unary FNeg support in LICM.
Aug 7 2019, 2:30 PM
cameron.mcinally committed rG303b6dbfb47c: [EarlyCSE] Add support for unary FNeg to EarlyCSE (authored by cameron.mcinally).
[EarlyCSE] Add support for unary FNeg to EarlyCSE
Aug 7 2019, 7:35 AM

Aug 6 2019

cameron.mcinally updated the diff for D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.

Updated patch for Joe's suggestion.

Aug 6 2019, 4:15 PM · Restricted Project
cameron.mcinally planned changes to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.
Aug 6 2019, 11:06 AM · Restricted Project, Restricted Project
cameron.mcinally updated the diff for D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.

Correct hash_combine(...) use.

Aug 6 2019, 10:18 AM · Restricted Project
cameron.mcinally planned changes to D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.

Ah, I misunderstood hash_combine(...). This patch needs work...

Aug 6 2019, 10:07 AM · Restricted Project
cameron.mcinally updated the diff for D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.

Remove unnecessary {}'s.

Aug 6 2019, 10:02 AM · Restricted Project
cameron.mcinally created D65815: [EarlyCSE] Add support for unary FNeg to EarlyCSE.
Aug 6 2019, 10:01 AM · Restricted Project
cameron.mcinally committed rG9c52f66f4822: [NFC][EarlyCSE] Pre-commit unary FNeg tests. (authored by cameron.mcinally).
[NFC][EarlyCSE] Pre-commit unary FNeg tests.
Aug 6 2019, 9:42 AM

Aug 1 2019

cameron.mcinally added inline comments to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.
Aug 1 2019, 12:06 PM · Restricted Project
cameron.mcinally added inline comments to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.
Aug 1 2019, 12:00 PM · Restricted Project
cameron.mcinally added inline comments to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.
Aug 1 2019, 9:07 AM · Restricted Project

Jul 31 2019

cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Kind of a larger question: Do we want to include the VisitUnaryMinus change into one mega-Diff? Or should we have several separate Diffs for each of the individual CreateFNeg(...) changes?

Jul 31 2019, 5:19 PM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Thanks for pointing this out, Craig. I do see VisitUnaryMinus(...) now. [I'm glad that Clang distinguished between the unary and binary fneg -- that could've been trouble. ;)]

Jul 31 2019, 1:41 PM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Sorry I wasn't very clear there. There are certainly places that use it, but the code for unary minus operator does not use CreateFNEG. it asks for the constant value to use for negation and the makes an fsub or sub depending on fp or int.

Jul 31 2019, 10:40 AM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Clang does not use the IRBuilder fneg entry point. When do we plan to switch clang over?

Jul 31 2019, 9:23 AM · Restricted Project, Restricted Project

Jul 30 2019

Herald added a reviewer for D61437: [AArch64] Static (de)allocation of SVE stack objects.: rengolin.
Jul 30 2019, 1:35 PM · Restricted Project

Jul 29 2019

cameron.mcinally added a comment to D65399: [InstCombine] canonicalize fneg before fmul/fdiv.

How about we add a TODO comment regarding Cameron's topic? Would that be sufficient?

Jul 29 2019, 11:59 AM · Restricted Project
cameron.mcinally added a comment to D65399: [InstCombine] canonicalize fneg before fmul/fdiv.

Saw that this was Accepted while I was writing my last comment...

Jul 29 2019, 11:45 AM · Restricted Project
cameron.mcinally added a comment to D65399: [InstCombine] canonicalize fneg before fmul/fdiv.
  1. The reassociation tests show that we were missing an optimization opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says that all of these transforms are allowed (regardless of binop/unop fneg version) because:

    "For all other operations [besides copy/abs/negate/copysign], this standard does not specify the sign bit of a NaN result."

    In all of these transforms, we always have some other binop (fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a potential intermediate NaN operand. (If that interpretation is wrong, then we must already have a bug in the existing transforms?)
Jul 29 2019, 11:37 AM · Restricted Project
cameron.mcinally committed rGb32a6592ebc4: [NFC][FPEnv] Pre-commit tests for canonicalize negated operand of fdiv. (authored by cameron.mcinally).
[NFC][FPEnv] Pre-commit tests for canonicalize negated operand of fdiv.
Jul 29 2019, 9:11 AM

Jul 25 2019

cameron.mcinally added a comment to D65226: [Strict FP] Allow custom operation actions.

I don't see a problem with scalarizing strict ops for Custom lowered nodes that would otherwise be legal. It's not ideal, I suppose, but if a target doesn't support the strict nodes in the backend, then it probably shouldn't be using the experimental intrinsics anyway.

Jul 25 2019, 10:16 AM · Restricted Project
cameron.mcinally added a comment to D65226: [Strict FP] Allow custom operation actions.
In D65226#1599743, @kpn wrote:

It looks like we're unrolling some vectors where before we weren't. That seems unfortunate. Is that the reason for the generated code quality regressions?

+1. What's the reason behind the scalarization?

Those are cases where the non-strict operation actually is not legal: e.g. the X86 target sets the operation action for FADD and FSUB vector operations to Custom. The old code simply ignored that and just emitted FADD and FSUB anyway as if they were legal, and only by chance did they match an isel pattern anyway.

The target can get the old behavior back by simply handling STRICT_FADD and STRICT_FSUB directly (presumably also via Custom operations similar to ones it uses for FADD/FSUB), so this is only a "regression" for the current fallback implementation.

Jul 25 2019, 9:09 AM · Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Another thought...

Jul 25 2019, 8:57 AM · Restricted Project, Restricted Project
cameron.mcinally added a comment to D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.

Ok, I think we're pretty close to having unary FNeg optimizations in line with binary FNeg optimizations. Is anyone aware of any obvious passes that I've missed?

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

Jul 24 2019

cameron.mcinally added a comment to D65226: [Strict FP] Allow custom operation actions.
In D65226#1599743, @kpn wrote:

It looks like we're unrolling some vectors where before we weren't. That seems unfortunate. Is that the reason for the generated code quality regressions?

Jul 24 2019, 2:40 PM · Restricted Project

Jul 19 2019

cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

Makes sense to me. As I recall, the mutation was always intended as a temporary solution.

Jul 19 2019, 1:16 PM · Restricted Project

Jul 17 2019

cameron.mcinally updated subscribers of D64746: Add constrained intrinsics for lrint and lround.
Jul 17 2019, 8:44 AM · Restricted Project

Jul 16 2019

cameron.mcinally added inline comments to D64746: Add constrained intrinsics for lrint and lround.
Jul 16 2019, 1:24 PM · Restricted Project
cameron.mcinally added inline comments to D64746: Add constrained intrinsics for lrint and lround.
Jul 16 2019, 1:23 PM · Restricted Project
cameron.mcinally accepted D64412: [Strict FP] Allow more relaxed scheduling.

This patch would add the additional option of also changing the relative order of the two strict_fmul operations.

Jul 16 2019, 7:32 AM · Restricted Project

Jul 15 2019

cameron.mcinally added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

I think I'll have to challenge you a little here. ;)

Jul 15 2019, 2:25 PM · Restricted Project
cameron.mcinally added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

Bah, my last comment was flawed! I read the test cases incorrectly and missed the 'fpexcept.ignore' on some of them.

Jul 15 2019, 12:20 PM · Restricted Project
cameron.mcinally added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

I'm reviewing the trap-safety issues now and have some open questions (language lawyers needed??). Let's say we have something like this:

Jul 15 2019, 12:12 PM · Restricted Project

Jul 12 2019

cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

Is there any chance I can get this patch into 9? What do I need to do to make that happen?

Jul 12 2019, 10:40 AM · Restricted Project
cameron.mcinally added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

How aggressive is LLVM's UB handling? Would it remove an entire block/function if UB is found in it?

If LLVM can prove a basic block unconditionally executes UB, it will be erased. But "unconditionally" is an important qualifier. For example, consider the following function: void f(void g()) { g(); *(int*)0 = 0; }. The call to g isn't erased because we can't prove g will return.

Jul 12 2019, 8:05 AM · Restricted Project

Jul 9 2019

cameron.mcinally updated subscribers of D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.
In D63782#1573780, @kpn wrote:

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?

Jul 9 2019, 9:47 AM · Restricted Project

Jul 8 2019

cameron.mcinally committed rG771769be9013: [Float2Int] Add support for unary FNeg to Float2Int (authored by cameron.mcinally).
[Float2Int] Add support for unary FNeg to Float2Int
Jul 8 2019, 7:49 AM