Page MenuHomePhabricator

rob.lougher (Robert Lougher)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 5 2014, 7:02 AM (266 w, 6 d)

Recent Activity

Sep 13 2019

rob.lougher added a comment to rL363169: StackProtector: Use PointerMayBeCaptured.

Unfortunately this commit causes a serious regression in SSP. I have raised bug 43308:

Sep 13 2019, 8:18 AM

Sep 2 2019

rob.lougher committed rG13190c422530: [TargetLowering][PS4] Add sincos(f) lib functions when target is PS4 (authored by rob.lougher).
[TargetLowering][PS4] Add sincos(f) lib functions when target is PS4
Sep 2 2019, 9:55 AM
rob.lougher updated the diff for D67009: [TargetLowering][PS4] Add sincos(f) lib functions when target is PS4.

Updated test3 and test3_errno to check that sinl+cosl does not get transformed into sincosl.

Sep 2 2019, 6:00 AM · Restricted Project

Aug 30 2019

rob.lougher created D67009: [TargetLowering][PS4] Add sincos(f) lib functions when target is PS4.
Aug 30 2019, 10:05 AM · Restricted Project

Jul 5 2019

rob.lougher committed rG9dcfbbae7623: This reverts r365061 and r365062 (test update) (authored by rob.lougher).
This reverts r365061 and r365062 (test update)
Jul 5 2019, 5:43 AM
rob.lougher committed rG2478b6209841: Revert r365198 as this accidentally commited something that should not have… (authored by rob.lougher).
Revert r365198 as this accidentally commited something that should not have…
Jul 5 2019, 5:35 AM
rob.lougher committed rG3bea2b15f536: This reverts r365061 and r365062 (test update) (authored by rob.lougher).
This reverts r365061 and r365062 (test update)
Jul 5 2019, 5:21 AM

Jul 3 2019

rob.lougher committed rG11953acb1377: [X86] Update test; NFC (authored by rob.lougher).
[X86] Update test; NFC
Jul 3 2019, 10:48 AM
rob.lougher committed rG720baf041639: [X86] Avoid SFB - Skip meta instructions (authored by rob.lougher).
[X86] Avoid SFB - Skip meta instructions
Jul 3 2019, 10:45 AM

Jul 1 2019

rob.lougher committed rGe20030f61217: [X86] Avoid SFB - Fix inconsistent codegen with/without debug info(2) (authored by rob.lougher).
[X86] Avoid SFB - Fix inconsistent codegen with/without debug info(2)
Jul 1 2019, 11:30 AM

May 23 2019

rob.lougher committed rG170dfeb2ff06: Resubmit r360436 "[X86] Avoid SFB - Fix inconsistent codegen with/without debug… (authored by rob.lougher).
Resubmit r360436 "[X86] Avoid SFB - Fix inconsistent codegen with/without debug…
May 23 2019, 11:14 AM

May 13 2019

rob.lougher committed rG91a9d4ef4b6e: Revert [X86] Avoid SFB - Fix inconsistent codegen with/without debug info (authored by rob.lougher).
Revert [X86] Avoid SFB - Fix inconsistent codegen with/without debug info
May 13 2019, 10:35 AM

May 10 2019

rob.lougher committed rG986b6b86bb8e: [X86] Avoid SFB - Fix inconsistent codegen with/without debug info (authored by rob.lougher).
[X86] Avoid SFB - Fix inconsistent codegen with/without debug info
May 10 2019, 8:54 AM

May 7 2019

rob.lougher committed rG8681ef8f41db: [InstCombine] Add new combine to add folding (authored by rob.lougher).
[InstCombine] Add new combine to add folding
May 7 2019, 12:35 PM
rob.lougher committed rG07298c9b1eed: Precommit tests for or/add transform. NFC. (authored by rob.lougher).
Precommit tests for or/add transform. NFC.
May 7 2019, 7:13 AM

May 3 2019

rob.lougher committed rGe28ab9354653: Revert r359549 - incorrect update of test checks. NFC (authored by rob.lougher).
Revert r359549 - incorrect update of test checks. NFC
May 3 2019, 8:13 AM

Apr 25 2019

rob.lougher committed rGd469133f95b7: [Evaluator] Walk initial elements when handling load through bitcast (authored by rob.lougher).
[Evaluator] Walk initial elements when handling load through bitcast
Apr 25 2019, 10:00 AM
rob.lougher updated the diff for D60793: [Evaluator] Walk initial elements when handling load through bitcast.

Added additional test from review comments.

Apr 25 2019, 7:12 AM · Restricted Project

Apr 18 2019

rob.lougher added a comment to D60793: [Evaluator] Walk initial elements when handling load through bitcast.

what's wrong with keeping it like it is?

Well, if it were possible to avoid the same computation for load I'd like to avoid it. However your patch seems to also handle cases when store is using GEP and load is using bitcast:

So let's stick with current approach. I'd probably include the example above as a test case.

Apr 18 2019, 5:26 AM · Restricted Project

Apr 17 2019

rob.lougher added a comment to D60793: [Evaluator] Walk initial elements when handling load through bitcast.

Can't operand 0 of bitcast (%union.A* %u) be used as a key?

Apr 17 2019, 10:57 AM · Restricted Project
rob.lougher added a comment to D60793: [Evaluator] Walk initial elements when handling load through bitcast.

"MutatedMemory" is only used to hold evaluated store values

It is also used to patch initializers - see BatchCommitValueTo

Apr 17 2019, 9:53 AM · Restricted Project
rob.lougher added a comment to D60793: [Evaluator] Walk initial elements when handling load through bitcast.

I wonder if it's possible to stop using MutatedMemory for checks in ComputeLoadResult and instead start using separate map which can also be filled
in EvaluateBlock. In this new map you can use bitcast (or even first operand of bitcast) as a key.

Apr 17 2019, 8:12 AM · Restricted Project
rob.lougher updated the diff for D60793: [Evaluator] Walk initial elements when handling load through bitcast.

Addressed review comments.

Apr 17 2019, 8:01 AM · Restricted Project

Apr 16 2019

rob.lougher updated the summary of D60793: [Evaluator] Walk initial elements when handling load through bitcast.
Apr 16 2019, 1:12 PM · Restricted Project
rob.lougher created D60793: [Evaluator] Walk initial elements when handling load through bitcast.
Apr 16 2019, 1:07 PM · Restricted Project

Mar 20 2019

rob.lougher committed rGf2158a8ef06c: Resubmit r356511 "[TailCallElim] Add tailcall elimination pass to LTO pipelines" (authored by rob.lougher).
Resubmit r356511 "[TailCallElim] Add tailcall elimination pass to LTO pipelines"
Mar 20 2019, 12:09 PM
rob.lougher committed rG364cb6b5d70a: [TailCallElim] Update tests for LTO pipeline change (authored by rob.lougher).
[TailCallElim] Update tests for LTO pipeline change
Mar 20 2019, 12:04 PM
rob.lougher created D59604: [LLD] Update tests for LTO pipeline change.
Mar 20 2019, 10:10 AM · Restricted Project

Mar 19 2019

rob.lougher added a comment to D58391: [TailCallElim] Add tailcall elimination pass to LTO Pipelines.

Sorry missed your earlier update. LGTM. Thanks for doing the measurements!

Mar 19 2019, 2:07 PM · Restricted Project
rob.lougher committed rGc67a759c9934: Revert r356511 "[TailCallElim] Add tailcall elimination pass to LTO pipelines" (authored by rob.lougher).
Revert r356511 "[TailCallElim] Add tailcall elimination pass to LTO pipelines"
Mar 19 2019, 1:54 PM
rob.lougher committed rGde548ccab9f1: [TailCallElim] Add tailcall elimination pass to LTO pipelines (authored by rob.lougher).
[TailCallElim] Add tailcall elimination pass to LTO pipelines
Mar 19 2019, 1:24 PM
rob.lougher added a comment to D58391: [TailCallElim] Add tailcall elimination pass to LTO Pipelines.

Ping.

Mar 19 2019, 11:00 AM · Restricted Project

Mar 12 2019

rob.lougher added a comment to D58391: [TailCallElim] Add tailcall elimination pass to LTO Pipelines.
Mar 12 2019, 10:58 AM · Restricted Project

Feb 19 2019

rob.lougher created D58391: [TailCallElim] Add tailcall elimination pass to LTO Pipelines.
Feb 19 2019, 10:40 AM · Restricted Project

Oct 23 2018

rob.lougher added a comment to D53519: [CodeGen] skip lifetime end marker in isInTailCallPosition.
In D53519#1273387, @rnk wrote:

I'd just land it as is. I think you're right, there's no reason to extend this with a local ad-hoc list, since those other two known intrinsics are unlikely to appear here.f

Oct 23 2018, 3:21 PM
rob.lougher added a comment to D53519: [CodeGen] skip lifetime end marker in isInTailCallPosition.
In D53519#1272775, @rnk wrote:

Is there some more general property for us to check that this intrinsic shares with other annotation-like intrinsics like llvm.assume?

I have a memory that somebody wanted an expands-to-nothing property, or generates-no-instructions, or something along those lines. That's probably the kind of generic property you're asking about here? I don't remember the context or outcome, unfortunately.

See my previous comment about ad hoc checks of intrinsic IDs in stack protector, loop vectorizer, etc.

Oct 23 2018, 3:18 PM
rob.lougher added a comment to D53519: [CodeGen] skip lifetime end marker in isInTailCallPosition.
In D53519#1272775, @rnk wrote:

Is there some more general property for us to check that this intrinsic shares with other annotation-like intrinsics like llvm.assume?

I have a memory that somebody wanted an expands-to-nothing property, or generates-no-instructions, or something along those lines. That's probably the kind of generic property you're asking about here? I don't remember the context or outcome, unfortunately.

Oct 23 2018, 2:53 PM
rob.lougher added a comment to D53519: [CodeGen] skip lifetime end marker in isInTailCallPosition.
In D53519#1272775, @rnk wrote:

Is there some more general property for us to check that this intrinsic shares with other annotation-like intrinsics like llvm.assume?

Oct 23 2018, 11:12 AM
rob.lougher added a reviewer for D53519: [CodeGen] skip lifetime end marker in isInTailCallPosition: rnk.
Oct 23 2018, 10:20 AM

Oct 22 2018

rob.lougher created D53519: [CodeGen] skip lifetime end marker in isInTailCallPosition.
Oct 22 2018, 11:57 AM

Oct 8 2018

rob.lougher closed D52895: [TailCallElim] Enable marking of calls with byval as tails.

Committed in rL343986 (apologies, I forgot the "Differential Revision:" tag)

Oct 8 2018, 11:32 AM

Oct 5 2018

rob.lougher updated the diff for D52895: [TailCallElim] Enable marking of calls with byval as tails.

I've updated the patch with the following changes:

Oct 5 2018, 7:55 AM

Oct 4 2018

rob.lougher updated the summary of D52895: [TailCallElim] Enable marking of calls with byval as tails.
Oct 4 2018, 6:07 PM
rob.lougher added a comment to D52895: [TailCallElim] Enable marking of calls with byval as tails.
Oct 4 2018, 6:00 PM
rob.lougher added a comment to D52895: [TailCallElim] Enable marking of calls with byval as tails.
In D52895#1255738, @rnk wrote:

Nice!

I don't understand the logical model behind byval, but I'll review the change to TRE under the assumption that the goal of the patch is correct.

You have to hallucinate an implicit memcpy into the call sequence. Its destination is some stack memory allocated during the call sequence not visible from LLVM IR.

How long does this pointer live? In a sequence with two byval calls on the same pointer, can they reuse the same memory, or it is always reallocated even if it happens to have the same address and contents?

Oct 4 2018, 4:49 PM
rob.lougher added a comment to D52895: [TailCallElim] Enable marking of calls with byval as tails.

Hi Nicholas and Reid,

Oct 4 2018, 4:23 PM
rob.lougher updated the summary of D52895: [TailCallElim] Enable marking of calls with byval as tails.
Oct 4 2018, 11:26 AM
rob.lougher added a comment to D52895: [TailCallElim] Enable marking of calls with byval as tails.
Oct 4 2018, 11:23 AM
rob.lougher updated the summary of D52895: [TailCallElim] Enable marking of calls with byval as tails.
Oct 4 2018, 10:57 AM
rob.lougher created D52895: [TailCallElim] Enable marking of calls with byval as tails.
Oct 4 2018, 10:54 AM

Aug 16 2018

rob.lougher updated the diff for D50798: [LoopVectorizer] Take into account call register pressure when selecting interleave count.

Added asserts to TTI functions to catch misuse.

Aug 16 2018, 12:20 PM
rob.lougher added inline comments to D50798: [LoopVectorizer] Take into account call register pressure when selecting interleave count.
Aug 16 2018, 10:43 AM

Aug 15 2018

rob.lougher added a comment to D48193: [LoopVectorizer] Use an interleave count of 1 when using a vector library call.

I've created a follow up review D50798.

Aug 15 2018, 12:44 PM
rob.lougher created D50798: [LoopVectorizer] Take into account call register pressure when selecting interleave count.
Aug 15 2018, 12:41 PM

Jul 2 2018

rob.lougher added a comment to D48193: [LoopVectorizer] Use an interleave count of 1 when using a vector library call.

This patch tries to fix improve the SVML calling convention. https://reviews.llvm.org/D47188 Maybe it will help this code?

Jul 2 2018, 9:49 AM

Jun 14 2018

rob.lougher added a comment to D48193: [LoopVectorizer] Use an interleave count of 1 when using a vector library call.

I see this as a register allocator problem. It's not like we are running out of registers so that we cannot use ymm0 as a "scratch register" for SVML call. We should show the ASM code to CG experts and get the problem fixed there.

Assuming that register allocator can fix simple enough issues..... I don't think it's correct to model this as a VECLIB call problem. It can happen to any function call that use too many registers that can't be shared among interleaved calls. Instead of looking at whether it's a VECLIB call or not, we should be checking how many registers are used for call/return, and how many of them cannot be shared among interleaved calls. We can then formulate this into a general register pressure issue.

The call uses one register but causes all other live values at the call location to be spilled (the other live values are caused by the interleaving). To model this we would need to know the calling-convention of the target (which registers are preserved), and also which registers the live values will end up in. This isn't known until after register allocation.

Craig topper told me that LLVM currently doesn't have any special knowledge on SVML's register usage. I just checked ICC behavior. ICC uses reg-reg move. So, there appears to be a room for improvement in that area.
I think it's better to look into that first. Doing something blindly like this look easy but I hate to see unnecessary restrictions to be imposed. Even if we don't have a great accuracy here, we should still try to do some accounting, especially so if the calls are to something that's better behaving than the worst case.

What's the value of Legal checking MayHaveVectorLibCall()? Cost model can tell whether the call is vector or scalar on its own for each VF, and that's already happened by the time selectInterleaveCount() is called.

Jun 14 2018, 6:09 PM
rob.lougher added a comment to D48193: [LoopVectorizer] Use an interleave count of 1 when using a vector library call.

I see this as a register allocator problem. It's not like we are running out of registers so that we cannot use ymm0 as a "scratch register" for SVML call. We should show the ASM code to CG experts and get the problem fixed there.

Assuming that register allocator can fix simple enough issues..... I don't think it's correct to model this as a VECLIB call problem. It can happen to any function call that use too many registers that can't be shared among interleaved calls. Instead of looking at whether it's a VECLIB call or not, we should be checking how many registers are used for call/return, and how many of them cannot be shared among interleaved calls. We can then formulate this into a general register pressure issue.

Jun 14 2018, 4:27 PM
rob.lougher updated subscribers of D48193: [LoopVectorizer] Use an interleave count of 1 when using a vector library call.
Jun 14 2018, 3:42 PM
rob.lougher added a comment to D48193: [LoopVectorizer] Use an interleave count of 1 when using a vector library call.

Hi Robert,

Jun 14 2018, 3:30 PM
rob.lougher added a comment to D48193: [LoopVectorizer] Use an interleave count of 1 when using a vector library call.

Hi Robert,

thanks for bringing this up! This approach is blindly setting the interleave factor to 1 when there are vector math function calls. I have the following questions/comments:

Jun 14 2018, 3:00 PM
rob.lougher created D48193: [LoopVectorizer] Use an interleave count of 1 when using a vector library call.
Jun 14 2018, 1:14 PM

May 9 2018

rob.lougher added a comment to D46599: [DbgInfo] Attempt to fix bug 37149.

I'll be interested to see what the lexical scopes are for your testcase in PR37149.

May 9 2018, 12:08 PM
rob.lougher added a comment to D46599: [DbgInfo] Attempt to fix bug 37149.

Have you ran the LLVM regression tests? In particular, does the test added in D35953 (test/DebugInfo/X86/live-debug-variables.ll) still work as expected?

May 9 2018, 10:52 AM

Feb 23 2018

rob.lougher added a comment to D43643: [RFC] Sceptre a Spectre variant 1 detector.

This is cut and pasted from an email reply as it's not showing up after over 2 hours...

Feb 23 2018, 12:10 PM

Feb 22 2018

rob.lougher updated the summary of D43643: [RFC] Sceptre a Spectre variant 1 detector.
Feb 22 2018, 12:46 PM
rob.lougher updated the summary of D43643: [RFC] Sceptre a Spectre variant 1 detector.
Feb 22 2018, 12:44 PM
rob.lougher created D43643: [RFC] Sceptre a Spectre variant 1 detector.
Feb 22 2018, 12:42 PM

Sep 12 2017

rob.lougher added a comment to D37625: [DWARF] Incorrect prologue end line record..

This was reverted in r313057 as it was causing buildbot failure (lldb inline stepping tests).

Sep 12 2017, 11:44 AM

Aug 1 2017

rob.lougher updated the diff for D35953: [LiveDebugVariables] Use lexical scope to trim debug value live intervals.

Address review comments. Now enabled for non-inlined variables. This required fixing a test to make it more resilient (it checks that we get the expected number of debug values, but was also enforcing a specific order). I've also changed where the LexicalScopes are generated, as they're only needed when computing the intervals.

Aug 1 2017, 11:45 AM

Jul 27 2017

rob.lougher created D35953: [LiveDebugVariables] Use lexical scope to trim debug value live intervals.
Jul 27 2017, 11:37 AM

Feb 10 2017

rob.lougher edited reviewers for D29833: Improve the API of DILocation::getMergedLocation(), added: rob.lougher; removed: dblaikie.
Feb 10 2017, 10:20 AM

Jan 12 2017

rob.lougher added a comment to D28521: [DebugInfo] Handle same locations in DILocation::getMergedLocation.

Added a couple of inline comments. LGTM with these changes applied.

Jan 12 2017, 5:49 PM

Jan 10 2017

rob.lougher retitled D28521: [DebugInfo] Handle same locations in DILocation::getMergedLocation from to [DebugInfo] Handle same locations in DILocation::getMergedLocation.
Jan 10 2017, 11:25 AM

Dec 15 2016

rob.lougher added a comment to D27590: [SimplifyCFG] In sinkLastInstruction correctly set the debug location of the "common" instruction.

LGTM too, FWIW!

Dec 15 2016, 8:26 AM

Dec 13 2016

rob.lougher added a comment to D26256: [InstCombine] Don't set debug location when folding through a phi node.

Ping. Adrian, are you happy with this revision?

Dec 13 2016, 10:42 AM

Dec 9 2016

rob.lougher added a comment to D27590: [SimplifyCFG] In sinkLastInstruction correctly set the debug location of the "common" instruction.
Dec 9 2016, 4:38 AM

Dec 8 2016

rob.lougher updated D27590: [SimplifyCFG] In sinkLastInstruction correctly set the debug location of the "common" instruction.
Dec 8 2016, 1:43 PM
rob.lougher added a parent revision for D27590: [SimplifyCFG] In sinkLastInstruction correctly set the debug location of the "common" instruction: D26256: [InstCombine] Don't set debug location when folding through a phi node.
Dec 8 2016, 1:41 PM
rob.lougher added a child revision for D26256: [InstCombine] Don't set debug location when folding through a phi node: D27590: [SimplifyCFG] In sinkLastInstruction correctly set the debug location of the "common" instruction.
Dec 8 2016, 1:41 PM
rob.lougher retitled D27590: [SimplifyCFG] In sinkLastInstruction correctly set the debug location of the "common" instruction from to [SimplifyCFG] In sinkLastInstruction correctly set the debug location of the "common" instruction.
Dec 8 2016, 1:40 PM

Dec 6 2016

rob.lougher updated the diff for D26256: [InstCombine] Don't set debug location when folding through a phi node.

I have updated the patch to add a new API for merging debug locations. As explained in the comments, the API is currently a stub which simply uses an empy location.

Dec 6 2016, 10:53 AM

Nov 21 2016

rob.lougher added a comment to D26256: [InstCombine] Don't set debug location when folding through a phi node.

Just a quick note to say I haven't forgotten about this.

Nov 21 2016, 7:52 AM

Nov 11 2016

rob.lougher retitled D26554: [LoopVectorizer] When estimating register usage, unused instructions may "end" another use. from to [LoopVectorizer] When estimating register usage, unused instructions may "end" another use..
Nov 11 2016, 12:24 PM

Nov 9 2016

rob.lougher added a comment to D26256: [InstCombine] Don't set debug location when folding through a phi node.

Thanks for all the comments. I'm away for the next couple of days - I'll check back on Monday.

Nov 9 2016, 5:43 PM
rob.lougher added a comment to D26256: [InstCombine] Don't set debug location when folding through a phi node.

No update. I looked into handling the single line if-then-else case and concluded it was not easy (as Dehao says at this stage you do not know the maximum discriminator value, without redoing the work of AddDiscriminators). As others want the patch could I add a TODO for now?

Nov 9 2016, 9:48 AM

Nov 2 2016

rob.lougher added a comment to D26256: [InstCombine] Don't set debug location when folding through a phi node.

Shouldn't it only drop the location if the two locations are distinct (and perhaps add a discriminator)?

Nov 2 2016, 1:24 PM
rob.lougher added a comment to D26256: [InstCombine] Don't set debug location when folding through a phi node.

Shouldn't it only drop the location if the two locations are distinct (and perhaps add a discriminator)?

Nov 2 2016, 1:19 PM
rob.lougher retitled D26256: [InstCombine] Don't set debug location when folding through a phi node from to [InstCombine] Don't set debug location when folding through a phi node.
Nov 2 2016, 12:29 PM

Oct 25 2016

rob.lougher added a comment to D25742: Remove debug location from common tail when tail-merging.

I've had to revert this as it caused a ubsan test to unexpectedly fail (vptr.cpp). As I don't know much about these tests I need to do some investigation into the failure. I suspect the test was reliant on a debug location from a common-tail.

Oct 25 2016, 1:33 PM
rob.lougher added a comment to D25742: Remove debug location from common tail when tail-merging.

ping...

Oct 25 2016, 9:50 AM

Oct 18 2016

rob.lougher added a comment to D25742: Remove debug location from common tail when tail-merging.

This approach seems generally fine, but I have one question:

If the code were on a single line, and both locations share a common ancestor scope, it seems make sense to create a new location using the common ancestor scope and line and only remove the column information.

That would collapse the if-then-else into (effectively) a single statement. That probably works okay for a debugger but not profiling, which still wants to treat the then/else as distinct. And, after the tail merging, the tails are no longer distinct.

I'm not sure I understand your point. How is having an orphaned add instruction preferable over having it associated with the collapsed if-then-else statement? Wouldn't I want that instruction to be counted towards the line?

No, the profiler wants to assign sample counts to each block individually. By giving each block the same source attribution, you assert that they have the same profiles. That's unlikely to be true in practice. Really what happens is that the sample counts would be assigned to the parent block, which doesn't help the profiler sort out what to do with the nested blocks.

Admittedly, zapping the source attribution on the merged (parts of the) blocks doesn't let you attribute those counts to *any* block, but at least you aren't attributing counts incorrectly.

Oct 18 2016, 7:03 PM
rob.lougher retitled D25742: Remove debug location from common tail when tail-merging from to Remove debug location from common tail when tail-merging.
Oct 18 2016, 11:33 AM

Jul 6 2016

rob.lougher updated subscribers of D22038: [X86] Transform zext+seteq+cmp into shr+lzcnt on btver2 architecture..
Jul 6 2016, 10:54 AM

Apr 29 2016

rob.lougher added a comment to D16298: Improve test coverage of -Wdouble-promotion.

No problem. Thanks for the code review.

Apr 29 2016, 10:44 AM

Apr 28 2016

rob.lougher added a comment to D16298: Improve test coverage of -Wdouble-promotion.

Ping.

Apr 28 2016, 10:23 AM

Mar 3 2016

rob.lougher added a comment to D16298: Improve test coverage of -Wdouble-promotion.

Ping. Please can somebody review this? Thanks!

Mar 3 2016, 5:44 AM

Feb 23 2016

rob.lougher added a comment to D16298: Improve test coverage of -Wdouble-promotion.

Ping. Just test changes - OK to commit?

Feb 23 2016, 5:00 AM

Jan 27 2016

rob.lougher added a comment to D16298: Improve test coverage of -Wdouble-promotion.

Ping.

Jan 27 2016, 3:32 AM

Jan 18 2016

rob.lougher retitled D16298: Improve test coverage of -Wdouble-promotion from to Improve test coverage of -Wdouble-promotion.
Jan 18 2016, 10:06 AM

Jan 12 2016

rob.lougher added a comment to D16067: Redundant vmov instruction generated with vcvtph2ps.

Hi Quentin,

Jan 12 2016, 3:50 AM