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 (263 w, 3 d)

Recent Activity

Wed, Jan 22

cameron.mcinally created D73212: [NFC][AArch64][SVE] Rename Destructive enumerator from DestructiveInstType.
Wed, Jan 22, 10:05 AM · Restricted Project
cameron.mcinally added a comment to D73141: [NFCI][AArch64][SVE] Set default DestructiveInstType in AArch64Inst class.

Bah, yeah, sorry. Copied the wrong number.

Wed, Jan 22, 7:20 AM · Restricted Project

Tue, Jan 21

cameron.mcinally created D73141: [NFCI][AArch64][SVE] Set default DestructiveInstType in AArch64Inst class.
Tue, Jan 21, 2:14 PM · Restricted Project
cameron.mcinally accepted D73057: [InstCombine] fneg(X + C) --> -C - X .

LGTM

Tue, Jan 21, 8:23 AM · Restricted Project
cameron.mcinally added inline comments to D73057: [InstCombine] fneg(X + C) --> -C - X .
Tue, Jan 21, 8:23 AM · Restricted Project

Fri, Jan 17

cameron.mcinally accepted D69878: Consoldiate internal denormal flushing controls.

LGTM too. Would be good if an expert reviewed the target-specific changes, but they seem safe enough either way.

Fri, Jan 17, 2:43 PM · Restricted Project
cameron.mcinally added inline comments to D72820: [FPEnv] Add pragma FP_CONTRACT support under strict FP..
Fri, Jan 17, 2:43 PM · Restricted Project, Restricted Project

Thu, Jan 16

cameron.mcinally added inline comments to D72820: [FPEnv] Add pragma FP_CONTRACT support under strict FP..
Thu, Jan 16, 1:55 PM · Restricted Project, Restricted Project
cameron.mcinally added inline comments to D72820: [FPEnv] Add pragma FP_CONTRACT support under strict FP..
Thu, Jan 16, 1:55 PM · Restricted Project, Restricted Project
cameron.mcinally added inline comments to D72820: [FPEnv] Add pragma FP_CONTRACT support under strict FP..
Thu, Jan 16, 1:55 PM · Restricted Project, Restricted Project

Fri, Jan 10

cameron.mcinally added inline comments to D69878: Consoldiate internal denormal flushing controls.
Fri, Jan 10, 11:48 AM · Restricted Project
cameron.mcinally added inline comments to D69878: Consoldiate internal denormal flushing controls.
Fri, Jan 10, 10:50 AM · Restricted Project

Wed, Jan 8

cameron.mcinally abandoned D71432: [AArch64][SVE] Proposal to use op+select to match scalable predicated operations.

I just checked out the PseudoOps and they're interesting. If we could make generic XXX_PSEUDO(..., %passthru) PseudoOps, that would be a good path forward. I don't foresee any problems adding an extra passthru operand to the existing patterns, but maybe I'm missing something. If you have any insight, it would be appreciated.

Awesome, thanks for checking this out.

I don't see many issues with adding the extra passthru operand, but it could do with a bit of prototyping; what we've done downstream was very specific to having the false lanes zero'd and that is actually unnecessarily restrictive (but we never really had to care for the generic case). The challenge would be in expanding the pseudo. For some pseudo for that has a reverse variant, e.g. Dst = fsub_pseudo(Pg, Op1, Op2, Passthru)

we would for example expand this as follows:

z0 = fsub_pseudo_S(p0, z1, z2, z3)
  <=>
sel z0.s, p0.s, z1.s, z3.s
fsub z0.s, p0/m, z2.s
 
z0 = fsub_pseudo_S(p0, z1, z2, z2)
  <=>
movprfx z0, z2
fsubr z2.s, p0/m, z1.s
 
or a special case for zero'd lanes:
 
z0 = fsub_pseudo_S(p0, z1, z2, <zero>)
movprfx z0, p0/z, z1
fsub z0.s, p0/m, z2.s

The indexed FMLA instruction has three input operands and this is a case where we can't relaxation the register constraints:

%dst = Pseudo_FMLA %a, %n, %m, %index
(to implement: %dst = FMLA %a + %n * %m[%index])

We cannot recover from a register allocation where %index is used as %dst, e.g.

Z0 = Pseudo_FMLA Z1, Z2, Z0, <index>

(there is no other variant we can use to recover from this, so those will need to retain a constraint that $Zd = $Zs1)

Wed, Jan 8, 7:31 AM · Restricted Project

Mon, Jan 6

cameron.mcinally added a comment to D69878: Consoldiate internal denormal flushing controls.

Ok, thanks for the clarifications. Looks good to me, but it would be good to have experts in OpenCL/Cuda/AMDGPU review the target specific changes.

Mon, Jan 6, 8:48 AM · Restricted Project

Fri, Jan 3

cameron.mcinally added a comment to D71432: [AArch64][SVE] Proposal to use op+select to match scalable predicated operations.

While we don't support the generic case in our downstream compiler, we do have special support for the cases where the false lanes are zeroed or undef. Using the predicated MOVPRFX instruction, the false lanes can be zeroed relatively cheaply using e.g.:

movprfx z0.s, p0/z, z1.s
fsub z0.s, p0/m, z2.s

This avoids having to emit an explicit sequence of a splat and select / predicated mov to zero the false lanes. We match the operation + select into a Pseudo instruction (e.g. FSUB_ZERO or FSUB_UNDEF), that is expanded after register allocation (in the AArch64ExpandPseudoInsts pass) into the appropriate instructions.

Even if we don't care about selecting a passthru value for the false lanes, there is still value in creating the Pseudo. The lack of a tied-operand constraint for the Pseudo gives the register allocator more freedom to come up with a better allocation. Combined with the commutative property of some instructions or by expanding to their reversed variants (like SUBR vs SUB), we can avoid a number of unnecessary register moves.

We've been thinking about some ideas on how to make this support more generic to allow supporting the general use-case of:

%Res = FSUB_PSEUDO(%Pred, %Op1, %Op2, %Passthru)

Depending on the value for %Passthru, this can be expanded to use a movprfx or in the worst case an explicit select.

Ideally we'd use a Pseudo for most operations so that we can use this as a generic mechanism that natively supports the passthru value and benefits from better register allocation.

A bit of prototyping would be required though, as our downstream compiler only covers a limited use-case. We've also had to deal with some corner-cases, but I'd need to refresh my memory on the details of those before I can comment on those. I'll try to dig up some more details!

Fri, Jan 3, 11:50 AM · Restricted Project

Thu, Jan 2

cameron.mcinally added a comment to D69878: Consoldiate internal denormal flushing controls.

This is looking pretty good to me, but I'm ignoring some of the target specific code that I'm not familiar with.

Thu, Jan 2, 9:49 AM · Restricted Project

Dec 13 2019

cameron.mcinally updated the diff for D71432: [AArch64][SVE] Proposal to use op+select to match scalable predicated operations.

Add a class for the op+select patterns.

Dec 13 2019, 12:51 PM · Restricted Project
cameron.mcinally accepted D71472: [AArch64][SVE] Implement pfirst and pnext intrinsics.

LGTM

Dec 13 2019, 9:10 AM · Restricted Project
cameron.mcinally added a comment to D71432: [AArch64][SVE] Proposal to use op+select to match scalable predicated operations.

Ah, ok. I see your point now.

Dec 13 2019, 7:56 AM · Restricted Project

Dec 12 2019

cameron.mcinally added a comment to D71432: [AArch64][SVE] Proposal to use op+select to match scalable predicated operations.

Adding patterns for vselect of various operations seems reasonable in general. The patterns are simple enough that it's not a big deal to repeat for a bunch of instructions.

Dec 12 2019, 5:57 PM · Restricted Project
cameron.mcinally updated the diff for D71432: [AArch64][SVE] Proposal to use op+select to match scalable predicated operations.

Remove some leftover debugging junk...

Dec 12 2019, 1:33 PM · Restricted Project
cameron.mcinally created D71432: [AArch64][SVE] Proposal to use op+select to match scalable predicated operations.
Dec 12 2019, 1:15 PM · Restricted Project

Dec 11 2019

cameron.mcinally committed rG7aa5c160885c: [AArch64][SVE] Add patterns for scalable vselect (authored by cameron.mcinally).
[AArch64][SVE] Add patterns for scalable vselect
Dec 11 2019, 6:16 PM
cameron.mcinally closed D71298: [AArch64][SVE] Add patterns for scalable vselect.
Dec 11 2019, 6:16 PM · Restricted Project
cameron.mcinally added a comment to D62731: Add support for options -frounding-math, -ftrapping-math, -ffp-model=, and -ffp-exception-behavior=, : Specify floating point behavior.

I've noticed you removed the change for CompilerInvocation.cpp about the initialization of the codegen option NoTrappingMath. Was that an accident?

Thanks again Michele. I'd like to get rid of Opts.NoTrappingMath, but I haven't been bold enough yet.

Dec 11 2019, 3:33 PM · Restricted Project, Restricted Project
cameron.mcinally added inline comments to D71298: [AArch64][SVE] Add patterns for scalable vselect.
Dec 11 2019, 3:06 PM · Restricted Project
cameron.mcinally added inline comments to D71298: [AArch64][SVE] Add patterns for scalable vselect.
Dec 11 2019, 2:29 PM · Restricted Project

Dec 10 2019

cameron.mcinally created D71298: [AArch64][SVE] Add patterns for scalable vselect.
Dec 10 2019, 1:42 PM · Restricted Project

Nov 27 2019

cameron.mcinally added a comment to D69281: [FPEnv] Constrained FCmp intrinsics.

Oh, or maybe I misunderstood. I assumed Andy meant a single intrinsics with an extra boolean argument, but now I'm not so sure...

Nov 27 2019, 10:27 AM · Restricted Project
cameron.mcinally 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 27 2019, 10:18 AM · Restricted Project

Nov 25 2019

cameron.mcinally accepted D70503: [TargetLowering] Merge ExpandChainLibCall with makeLibCall.

LGTM

Nov 25 2019, 8:52 AM · Restricted Project
cameron.mcinally accepted D70599: [ARM] Add constrained FP intrinsics test.

LGTM

Nov 25 2019, 8:24 AM · Restricted Project

Nov 20 2019

cameron.mcinally updated subscribers of D69989: Assume ieee behavior without denormal-fp-math attribute.

Attn: @craig.topper @eli.friedman. The FMF behavior looks like it will take a performance hit with the switch to default IEEE conformance. Is this something that needs to be publicized on llvm-dev before merging? Users who don't care will want to add an explicit denormal-fp-math attribute to their code.

Nov 20 2019, 9:08 AM · Restricted Project

Nov 19 2019

cameron.mcinally requested changes to D69989: Assume ieee behavior without denormal-fp-math attribute.

Ah, I didn't realize there were test differences from this change. It should probably be combined with D69988...

Nov 19 2019, 12:43 PM · Restricted Project
cameron.mcinally accepted D69989: Assume ieee behavior without denormal-fp-math attribute.

LGTM

Nov 19 2019, 12:24 PM · Restricted Project

Nov 18 2019

cameron.mcinally added inline comments to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
Nov 18 2019, 10:40 AM · Restricted Project
cameron.mcinally added inline comments to D69891: [VP,Integer,#1] Vector-predicated integer intrinsics.
Nov 18 2019, 9:02 AM · Restricted Project

Nov 14 2019

cameron.mcinally accepted D70208: [SimplifyCFG] propagate fast-math-flags (FMF) from phi to select.

LGTM

Nov 14 2019, 8:52 AM · Restricted Project

Nov 12 2019

cameron.mcinally added inline comments to D69281: [FPEnv] Constrained FCmp intrinsics.
Nov 12 2019, 10:00 AM · Restricted Project
cameron.mcinally added inline comments to D69281: [FPEnv] Constrained FCmp intrinsics.
Nov 12 2019, 8:36 AM · Restricted Project
cameron.mcinally added inline comments to D69281: [FPEnv] Constrained FCmp intrinsics.
Nov 12 2019, 8:09 AM · Restricted Project
cameron.mcinally added a comment to D69547: DAG: Add function context to isFMAFasterThanFMulAndFAdd.

Adding @spatel and @eli.friedman. My confidence level is low for this review...

Nov 12 2019, 7:41 AM · Restricted Project
cameron.mcinally added a reviewer for D69547: DAG: Add function context to isFMAFasterThanFMulAndFAdd: eli.friedman.
Nov 12 2019, 7:41 AM · Restricted Project
cameron.mcinally added a reviewer for D69547: DAG: Add function context to isFMAFasterThanFMulAndFAdd: spatel.
Nov 12 2019, 7:41 AM · Restricted Project

Nov 11 2019

cameron.mcinally added a comment to D69281: [FPEnv] Constrained FCmp intrinsics.

Oh, it's gone now. Maybe it was a temporary hiccup. Will review this afternoon...

Nov 11 2019, 10:13 AM · Restricted Project
cameron.mcinally added a comment to D69281: [FPEnv] Constrained FCmp intrinsics.

Hmm, something is weird (with my Diff, at least). It looks like changes are listed twice (e.g. lib/IR/Verifier.cpp and llvm/lib/IR/Verifier.cpp). Maybe this is an SVN->GIT side-effect and the patch needs a rebase?

Nov 11 2019, 9:08 AM · Restricted Project
cameron.mcinally added a comment to D70080: [AArch64][SVE] Allocate locals that are scalable vectors..

LGTM. Will give other reviewers some time to review though...

Nov 11 2019, 8:22 AM · Restricted Project

Oct 31 2019

cameron.mcinally added inline comments to D69547: DAG: Add function context to isFMAFasterThanFMulAndFAdd.
Oct 31 2019, 9:06 AM · Restricted Project
cameron.mcinally added a comment to D69547: DAG: Add function context to isFMAFasterThanFMulAndFAdd.

Is isFMAFasterThanFMulAndFAdd's MachineFunction argument currently used? Or is that coming in a follow-up Diff? I might have missed it...

Oct 31 2019, 8:19 AM · Restricted Project

Oct 30 2019

cameron.mcinally added a comment to D69539: DAG: Add DAG argument to isFPExtFoldable.

LGTM

Oct 30 2019, 7:30 AM · Restricted Project
cameron.mcinally accepted D69539: DAG: Add DAG argument to isFPExtFoldable.
Oct 30 2019, 7:28 AM · Restricted Project

Oct 29 2019

cameron.mcinally accepted D69521: DAG: Add new control for ISD::FMAD formation.

LGTM

Oct 29 2019, 12:09 PM · Restricted Project
cameron.mcinally added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

LLVM is a very fast moving target, stopping the world to get the IR "right" doesn't work.

A good example to look for is the scalable vector IR changes that have gone through multiple attempts and are going on for many years and still not complete...

These things take time, rushing it usually backfires. :)

Oct 29 2019, 9:09 AM · Restricted Project
cameron.mcinally updated subscribers of D69521: DAG: Add new control for ISD::FMAD formation.

This looks good. Is it possible to write tests for the AMDGPU specific change?

Oct 29 2019, 8:53 AM · Restricted Project
cameron.mcinally added inline comments to D69275: Add constrained int->FP intrinsics.
Oct 29 2019, 8:40 AM · Restricted Project
cameron.mcinally added a comment to D69275: Add constrained int->FP intrinsics.
In D69275#1725323, @kpn wrote:

This probably needs tests that will lower to single instructions. E.g. llvm.experimental.constrained.uitofp.v4f32.v4i32 should lower to a cvtps2dq on SSE2.

Maybe testing an AVX512VL target would be interesting too. They have really good support for different CVT variants.

For a first cut I was hoping to avoid dealing with Custom lowerings. That's why there's no v4* test cases. Is this something that can be handled when the X86 backend support gets to this point?

Oct 29 2019, 8:34 AM · Restricted Project
cameron.mcinally added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

Code explosion is the symptom, not the sickness. It's caused by using experimental intrinsics. Experimental intrinsics are a detriment to progress. They end up creating a ton more work and are designed to be inevitably replaced.

I think this is a big hammer argument for a nuanced topic.

Oct 29 2019, 8:21 AM · Restricted Project

Oct 28 2019

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

DevMtg Summary

  • There will be a separate RFC for the generalized pattern rewriting logic in LLVM-VP (see PatternMatch.h). We do this because it is useful for other efforts as well, eg to make the existing pattern rewrites in InstSimplify/Combine, DAGCombiner work also for constrained fp (@uweigand ) and complex arithmetic (@greened) . This may actually speedup things since we can pursue VP and generalized pattern match in parallel.
Oct 28 2019, 2:28 PM · Restricted Project
cameron.mcinally added a comment to D57504: RFC: Prototype & Roadmap for vector predication in LLVM.

Are predicated vector instructions not just a special case of DemandedBits? Why can't we leave out the .vp. intrinsics, and just generate the predicate with DemandedBits? That way you do a predicated vector operation like so (in zig): As the example makes clear, this optimization would have to be guaranteed in order for the generated code to be correct (as the predicate avoids a divide-by-zero error).

var notzero = v != 0;
if (std.vector.any(notzero)) {

v = std.vector.select(5 / v, v, notzero);

}

What you describe is a workaround but not a solution for predicated SIMD in LLVM.
This approach may seem natural considering SIMD ISAs, such as x86 SSE, ARM NEON, that do not have predication.
It is however a bad fit for SIMD instruction sets that do support predicated SIMD (AVX512, ARM SVE, RISC-V V, NEC SX-Aurora).

As it turns out, it is more robust to have predicated instructions right in LLVM IR and convert them to the instruction+select pattern for SSE and friends than going the other way round.
This is what LLVM-VP proposes.

Oct 28 2019, 1:52 PM · Restricted Project
cameron.mcinally added a comment to D69275: Add constrained int->FP intrinsics.

This probably needs tests that will lower to single instructions. E.g. llvm.experimental.constrained.uitofp.v4f32.v4i32 should lower to a cvtps2dq on SSE2.

Oct 28 2019, 1:29 PM · Restricted Project
cameron.mcinally added a comment to D69281: [FPEnv] Constrained FCmp intrinsics.

I did not actually require any TableGen changes, but was able to represent the overloaded intrinsic types using existing mechanisms. This solution looks correct to me, but if I'm missing anything here, please let me know ...

Oct 28 2019, 9:20 AM · Restricted Project
cameron.mcinally accepted D69396: [IR] Use UnaryOperator::CreateFNeg in NoFolder::createFNeg.

Good catch. Thanks. LGTM.

Oct 28 2019, 8:19 AM · Restricted Project

Oct 14 2019

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

Both the ASan build:

Oct 14 2019, 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
Oct 14 2019, 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...

Oct 14 2019, 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...

Oct 14 2019, 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...

Oct 14 2019, 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
Oct 14 2019, 8:34 AM

Oct 10 2019

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:

Oct 10 2019, 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

Oct 10 2019, 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.

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

Oct 9 2019

cameron.mcinally accepted D68748: Add FMF to vector ops for phi.
Oct 9 2019, 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
Oct 9 2019, 2:55 PM
cameron.mcinally closed D61675: [WIP] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator.
Oct 9 2019, 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...

Oct 9 2019, 7:58 AM · Restricted Project

Oct 8 2019

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.

Oct 8 2019, 1:14 PM · Restricted Project, Restricted Project
cameron.mcinally added inline comments to D68203: Add support for (expressing) vscale..
Oct 8 2019, 12:22 PM · Restricted Project
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.

Oct 8 2019, 12:12 PM
cameron.mcinally added a comment to D68203: Add support for (expressing) vscale..

What happens if we see IR like:

Oct 8 2019, 11:44 AM · Restricted Project
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.

Oct 8 2019, 8:26 AM · Restricted Project

Oct 7 2019

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
Oct 7 2019, 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
Oct 7 2019, 10:19 PM
cameron.mcinally created D68588: [Bitcode] Update naming of UNOP_NEG to UNOP_FNEG.
Oct 7 2019, 1:02 PM · Restricted Project
cameron.mcinally added inline comments to D67749: [AArch64] Stackframe accesses to SVE objects..
Oct 7 2019, 12:41 PM · Restricted Project
cameron.mcinally added inline comments to D53877: [IR] Strawman for dedicated FNeg IR instruction.
Oct 7 2019, 9:05 AM · Restricted Project
cameron.mcinally added inline comments to D53877: [IR] Strawman for dedicated FNeg IR instruction.
Oct 7 2019, 8:25 AM · Restricted Project
cameron.mcinally added inline comments to D67749: [AArch64] Stackframe accesses to SVE objects..
Oct 7 2019, 7:34 AM · Restricted Project

Oct 1 2019

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

LGTM

Oct 1 2019, 8:56 AM · Restricted Project

Sep 24 2019

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.:

Sep 24 2019, 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