Page MenuHomePhabricator
Feed Advanced Search

Tue, Jun 4

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.

Tue, Jun 4, 2:13 PM · Restricted Project

Mon, Jun 3

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.

Mon, Jun 3, 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
Mon, Jun 3, 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.

Mon, Jun 3, 9:21 AM · Restricted Project

Wed, May 29

andrew.w.kaylor updated the diff for D62560: Fix a crash when the default of a switch is removed.

Updated test case

Wed, May 29, 2:39 PM · Restricted Project

Tue, May 28

andrew.w.kaylor created D62560: Fix a crash when the default of a switch is removed.
Tue, May 28, 5:17 PM · Restricted Project
andrew.w.kaylor added a comment to D59780: Support Intel Control-flow Enforcement Technology.

I was also wondering if there has been any progress with this. Was there any more discussion on the ABI mailing list?

Tue, May 28, 11:37 AM · Restricted Project

Mon, May 20

andrew.w.kaylor added inline comments to D53157: Teach the IRBuilder about constrained fadd and friends.
Mon, May 20, 2:12 PM

May 14 2019

andrew.w.kaylor accepted D61916: Teach InstSimplify transform -X + X --> 0.0 about unary FNeg.

lgtm

May 14 2019, 4:01 PM · Restricted Project

May 1 2019

andrew.w.kaylor accepted D61331: [SelectionDAG] remove constant folding limitations based on FP exceptions.

I'm OK with this. Thanks for the TODO comment!

May 1 2019, 1:23 PM · Restricted Project
andrew.w.kaylor added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
May 1 2019, 1:16 PM · Restricted Project
andrew.w.kaylor added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
May 1 2019, 11:25 AM · Restricted Project

Apr 30 2019

andrew.w.kaylor added a comment to D61331: [SelectionDAG] remove constant folding limitations based on FP exceptions.

We generally try to avoid keeping dead code in-tree, but I guess I'm not strongly opposed to it here.

Apr 30 2019, 1:49 PM · Restricted Project
andrew.w.kaylor added a comment to D61331: [SelectionDAG] remove constant folding limitations based on FP exceptions.

Why wouldn't we want to reuse this code path?

Apr 30 2019, 12:55 PM · Restricted Project
andrew.w.kaylor added a comment to D61331: [SelectionDAG] remove constant folding limitations based on FP exceptions.

Rather than get rid of this, can we update it to handle strict FP nodes correctly? Or at least put a skeleton in place to prepare to handle it correctly?

Apr 30 2019, 12:32 PM · Restricted Project

Apr 29 2019

andrew.w.kaylor added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Apr 29 2019, 11:41 AM · Restricted Project

Apr 26 2019

andrew.w.kaylor added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Apr 26 2019, 6:20 PM · Restricted Project

Apr 25 2019

andrew.w.kaylor added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Apr 25 2019, 3:07 PM · Restricted Project

Apr 17 2019

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

According to the LLVM langref, "fpexcept.ignore" seems to be the right option for exceptions whereas there is no "round.permissive" option for the rounding behavior. Abusing rmInvalid/ebInvalid seems hacky.

Apr 17 2019, 11:21 AM · Restricted Project

Apr 10 2019

andrew.w.kaylor accepted D59833: [FPEnv] New document for adding new constrained FP intrinsics.

lgtm

Apr 10 2019, 12:59 PM · Restricted Project

Mar 27 2019

andrew.w.kaylor added inline comments to D59833: [FPEnv] New document for adding new constrained FP intrinsics.
Mar 27 2019, 11:59 AM · Restricted Project

Mar 21 2019

andrew.w.kaylor updated subscribers of D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.
Mar 21 2019, 5:52 PM · Restricted Project
andrew.w.kaylor updated subscribers of D55897: Add constrained fptrunc and fpext intrinsics.
Mar 21 2019, 5:48 PM · Restricted Project
andrew.w.kaylor added a comment to D57970: [WinEH] Allocate unique stack slots for xmm CSRs in funclets.

I haven't had time to work on the alternate approach suggested, but one of my colleagues is working on it.

Mar 21 2019, 5:27 PM · Restricted Project

Feb 26 2019

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

Yes, the chain prevents redordering of floating point instructions by SelectionDAG. But it's fine to reorder instructions with static rounding mode(and ignore exception) and no need for chain. Because they do not have side effect, it means the result of such instructions only depend on input (eg, float add including source operands and mode encoding), does not depend on outside state variable that is current rounding mode. It also means the result is unchanged no matter how many times happens so long as the input is same.

Feb 26 2019, 10:17 AM · Restricted Project

Feb 21 2019

andrew.w.kaylor added a comment to D58406: Fix IR/Analysis layering issue in OptBisect.

For the record, I'm not sure about the previous decision that passing strings is too expensive. On the one hand, bisection is almost always disabled and is disabled in 100% of cases where anyone cares about compile time (though that may not be true of all opt gate use cases). On the other hand, even for a relatively large file with many functions and loops this is going to be on the order of 200,000 calls to this interface. Sure, building 200,000 strings isn't cheap, but in a compilation that's running 200,000 optimization passes it's minuscule.

Feb 21 2019, 9:47 AM · Restricted Project

Feb 13 2019

andrew.w.kaylor added a comment to D57970: [WinEH] Allocate unique stack slots for xmm CSRs in funclets.

I haven't had a lot more time to spend on this, but I did do a bit of investigation. I still only have a vague idea of what would be required to implement hard-coded offsets, but it didn't look to me like there is existing infrastructure for this so all of the things that just kind of magically worked with this patch (like growing the stack allocation and writing the .seh_savexmm directive) would need to be explicitly updated, right?

Feb 13 2019, 5:47 PM · Restricted Project

Feb 8 2019

andrew.w.kaylor added inline comments to D57970: [WinEH] Allocate unique stack slots for xmm CSRs in funclets.
Feb 8 2019, 1:39 PM · Restricted Project
andrew.w.kaylor created D57970: [WinEH] Allocate unique stack slots for xmm CSRs in funclets.
Feb 8 2019, 12:25 PM · Restricted Project

Jan 30 2019

andrew.w.kaylor added a comment to D55897: Add constrained fptrunc and fpext intrinsics.

This is looking pretty good. I don't think I know the Selection DAG well enough to offer a proper review of that. I'll see if I can get Craig's attention on it.

Jan 30 2019, 12:46 PM · Restricted Project
andrew.w.kaylor added inline comments to D55897: Add constrained fptrunc and fpext intrinsics.
Jan 30 2019, 11:09 AM · Restricted Project

Jan 8 2019

andrew.w.kaylor added inline comments to D54649: [FPEnv] Rough out constrained FCmp intrinsics.
Jan 8 2019, 5:25 PM · Restricted Project

Jan 2 2019

andrew.w.kaylor added inline comments to D54649: [FPEnv] Rough out constrained FCmp intrinsics.
Jan 2 2019, 4:24 PM · Restricted Project

Dec 18 2018

andrew.w.kaylor added inline comments to D54649: [FPEnv] Rough out constrained FCmp intrinsics.
Dec 18 2018, 11:21 AM · Restricted Project

Dec 17 2018

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

This looks like a promising direction. I particularly like the idea of having a way to intersect information from the backend instruction definitions with the constraints coming from the IR. However, I also have some concerns.

Dec 17 2018, 4:19 PM · Restricted Project
andrew.w.kaylor added a comment to D54649: [FPEnv] Rough out constrained FCmp intrinsics.

I'm a bit out of my depth with the tablegen type handling stuff. I have some minor comments regarding naming consistency. Everything looks reasonable to me.

Dec 17 2018, 11:34 AM · Restricted Project

Nov 28 2018

andrew.w.kaylor accepted D53773: [ExecutionEngine] Track objects using an abstract ObjectKey in JITEventListeners..

Looks good to me too.

Nov 28 2018, 3:20 PM

Nov 27 2018

andrew.w.kaylor accepted D54926: [TableGen] Preprocessing support.

Thanks for posting the incremental revision.

Nov 27 2018, 9:43 AM

Nov 20 2018

andrew.w.kaylor added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

The problem I was missing is when a FENV_ACCESS=OFF operation, like a FDIV, is hoisted into a FENV_ACCESS=ON region. I see it now, but still think that forcing FENV_ACCESS=OFF operations into constrained intrinsics is a big hammer. If there is a way to add barriers around function calls in a FENV_ACCESS=ON region, that would be better.

Nov 20 2018, 5:14 PM

Nov 19 2018

andrew.w.kaylor added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

A couple of comments on the previous discussion:

  1. Instead of defining a new command line option, I'd prefer to use the existing options -frounding-math and -ftrapping-math to set the default behavior of math operations w.r.t. rounding modes and exception status. (For compatibility with GCC if nothing else.)
Nov 19 2018, 10:47 AM

Nov 16 2018

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

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

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

Also, some AVX512 hardware instructions have explicit SAE and RM operands.

Nov 16 2018, 1:46 PM

Nov 13 2018

andrew.w.kaylor abandoned D53678: Include llvm-config.h from Demangle/Compiler.h.
Nov 13 2018, 4:53 PM

Nov 8 2018

andrew.w.kaylor added a comment to D45616: [X86] Lower _mm[256|512]_cmp[.]_mask intrinsics to native llvm IR.

Agreed. Reverting this patch wouldn't move us forward on constrained FP handling. What I'm saying (and what I think @nastafev is saying) is that this patch is taking a built-in that allows the user to express specific signalling behavior and throwing away that aspect of its semantics. Granted we do say that FP environment access is unsupported, so technically unmasking FP exceptions or even reading the status flag is undefined behavior. But it seems like there's a pretty big difference between using that claim to justify enabling some optimization that might do constant folding in a way that assumes the default rounding mode versus using that claim to disregard part of the semantics of a built-in that is modeling a target-specific instruction.

Nov 8 2018, 3:51 PM
andrew.w.kaylor added a comment to D45616: [X86] Lower _mm[256|512]_cmp[.]_mask intrinsics to native llvm IR.
can trigger arbitrary floating-point exceptions anywhere in your code

I believe this statement reflects the current state of many compilers on the market, I guess I just don't see the reason why making things worse. It seems the original intent of the commit was to add support for masked compares, and that could have been achieved without breaking what already worked.

I hope the patch is ultimately helping some performance optimization, but it is breaking the original intent of some legitimate programs that worked before, and introduces correctness regression. So to me it must be at least guarded by a flip-switch.

The reference to constrained floating-point intrinsics work is relevant, but it will obviously take time and extra effort to enable and then to unbreak all the cases that are made broken here. Instead one could postpone lowering of the particular instructions until it was possible without violation of the semantics...

Nov 8 2018, 2:04 PM
andrew.w.kaylor added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

Craig Topper also raised some concerns with me (in person, his desk is right by mine) about the potential effect this might have on code size. He tells me that IRBuilder calls are intended to always be inlined and if we grow the implementation of these functions too much it could lead to noticeable bloat. It still seems to me like it might be worthwhile for the simplification it would allow in the front end, but I'm not really a front end guy so I definitely agree that we should get some input from front end people about what they want.

Nov 8 2018, 11:39 AM

Nov 7 2018

andrew.w.kaylor added a comment to D54121: [FPEnv] Add constrained FCMP intrinsic.
compareSignalingGreaterEqual(a,b) is equivalent to compareSignalingLessUnordered(b, a)
Nov 7 2018, 4:34 PM
andrew.w.kaylor added a comment to D54121: [FPEnv] Add constrained FCMP intrinsic.

I think my preference would be to have the predicate in the function name. I briefly toyed with the idea of hacking AsmWriter to print a constant integer as the corresponding predicate string, but I think that would look too weird. Also, I don't think we should open the door to something trying to use the value that represents the predicate as if it were a real value. In this sense the predicate argument, if we had one, should really be a token but I don't think we want to add new token constants just for this.

Nov 7 2018, 2:44 PM
andrew.w.kaylor added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

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

Nov 7 2018, 10:17 AM

Nov 5 2018

andrew.w.kaylor added a comment to D54121: [FPEnv] Add constrained FCMP intrinsic.

This is definitely a tricky case. I don't really like any of the available solutions. I'll try to think more about it, and maybe someone else will have a brilliant suggestion.

Nov 5 2018, 4:17 PM

Nov 2 2018

andrew.w.kaylor accepted D53411: [FPEnv] Add constrained CEIL/FLOOR/ROUND/TRUNC intrinsics.

This looks good, except that I assume now you'll be removing the FMA checks from the tests.

Nov 2 2018, 4:00 PM
andrew.w.kaylor accepted D53932: [NFCI][FPEnv] Split constrained intrinsic tests.

lgtm

Nov 2 2018, 3:50 PM
andrew.w.kaylor added inline comments to D53773: [ExecutionEngine] Track objects using an abstract ObjectKey in JITEventListeners..
Nov 2 2018, 3:46 PM
andrew.w.kaylor added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.

I think we both agree that it's undefined behavior. If that's correct, then it doesn't really matter what we do after we hit it. So any solution is acceptable...

Nov 2 2018, 2:16 PM
andrew.w.kaylor added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.

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

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

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

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

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

I'm not an expert on inlining, but I imagine there are challenges moving it to 1st in the pass order too. I could see it being difficult to analyze cost on an unoptimized, non-canonical IR.

Nov 2 2018, 11:12 AM
andrew.w.kaylor added a comment to D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics.

I'm realizing that FENV_ACCESS is poorly designed.

Nov 2 2018, 11:07 AM

Nov 1 2018

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

...

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

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

Nov 1 2018, 5:48 PM

Oct 25 2018

andrew.w.kaylor added inline comments to D53538: NFC: Reorganize the demangler a bit.
Oct 25 2018, 10:55 AM

Oct 24 2018

andrew.w.kaylor added a comment to D53678: Include llvm-config.h from Demangle/Compiler.h.

FYI: this will be fixed by https://reviews.llvm.org/D53538 when that lands.

Oct 24 2018, 3:48 PM
andrew.w.kaylor created D53678: Include llvm-config.h from Demangle/Compiler.h.
Oct 24 2018, 3:37 PM

Oct 9 2018

andrew.w.kaylor added inline comments to D52452: Change the timestamp of llvmcache-foo file to meet the thinLTO prune policy.
Oct 9 2018, 5:41 PM

Oct 1 2018

andrew.w.kaylor added a comment to D52709: Add -instcombine-code-sinking option.

Can you update this review with a summary that describes the problem your are trying to fix by disabling instruction sinking here?

Oct 1 2018, 9:37 AM

Sep 25 2018

andrew.w.kaylor added a comment to D50913: [FPEnv] Don't need copysign/fabs/fneg constrained intrinsics.

There hasn't been any strong objects, but I haven't seen many strong accepts either besides the few main stakeholders. I'm under the assumption that silence is a passive reject in situations like this.

Should I keep pushing for it? It felt like I was beating a dead horse...

Sep 25 2018, 8:39 AM

Sep 18 2018

andrew.w.kaylor added inline comments to D47858: [New PM] Introducing PassInstrumentation framework.
Sep 18 2018, 3:10 PM
andrew.w.kaylor added inline comments to D47858: [New PM] Introducing PassInstrumentation framework.
Sep 18 2018, 2:50 PM
andrew.w.kaylor added inline comments to D47858: [New PM] Introducing PassInstrumentation framework.
Sep 18 2018, 2:46 PM
andrew.w.kaylor added inline comments to D47858: [New PM] Introducing PassInstrumentation framework.
Sep 18 2018, 2:25 PM

Aug 23 2018

andrew.w.kaylor added a comment to D50913: [FPEnv] Don't need copysign/fabs/fneg constrained intrinsics.

This is more a question of lowering and not an IR semantics question. The fneg will be defined as having no side effects or trapping. If through some architectural specific quirk the expected instructions need something more to avoid this, then that is their issue to deal with. Since it should always be impleentable with bitwise operations, this shouldn't be an issue

Aug 23 2018, 2:53 PM
andrew.w.kaylor added a comment to D50913: [FPEnv] Don't need copysign/fabs/fneg constrained intrinsics.

Your argument here is compelling. If there's no guarantee that an FSUB and FNEG are disjoint, then this won't work. Although, an FSUB and FNEG aren't really the same operation. Perhaps we should only be doing the transformation under UnsafeMath conditions to begin with...

Aug 23 2018, 12:30 PM

Aug 21 2018

andrew.w.kaylor added a comment to D50913: [FPEnv] Don't need copysign/fabs/fneg constrained intrinsics.

I feel like it might be a bad idea to have floating point instructions that don't have constrained forms.

Aug 21 2018, 1:56 PM

Aug 2 2018

andrew.w.kaylor added a comment to D49403: More aggressively complete RecordTypes with Function Pointers.

Fair enough.

Aug 2 2018, 5:50 PM
andrew.w.kaylor added a comment to D49403: More aggressively complete RecordTypes with Function Pointers.

I hope I'm not coming across as too argumentative here. I don't really have strong feelings about this function pointer type patch and ultimately I see that you are right, but the objections you are raising here would equally apply to what I'm working on with the IR linker and if I find a way to fix that, I'll care a bit more about that case. (If you'd like a preview, here's the bug I'm trying to fix: https://bugs.llvm.org/show_bug.cgi?id=38408)

Aug 2 2018, 11:56 AM

Aug 1 2018

andrew.w.kaylor added a comment to D49403: More aggressively complete RecordTypes with Function Pointers.

The LLVM linker also seems to have a bunch of problems with resolving pointer types in structures. I'm looking into a couple of those now.

Aug 1 2018, 4:25 PM
andrew.w.kaylor added a comment to D49403: More aggressively complete RecordTypes with Function Pointers.

I've talked to Olga about this, and I think we have a way to handle the problem she was working on without this change.

Aug 1 2018, 11:37 AM

Jun 14 2018

andrew.w.kaylor added a comment to D47925: Add debug info for OProfile porifling support.

Great! Sorry but I do not have merge access, can you land this for me? Thanks!

Jun 14 2018, 3:53 PM

Jun 13 2018

andrew.w.kaylor accepted D47925: Add debug info for OProfile porifling support.

lgtm

Jun 13 2018, 2:32 PM

Jun 11 2018

andrew.w.kaylor added inline comments to D47491: Expand constrained FP operations.
Jun 11 2018, 4:26 PM

Jun 8 2018

andrew.w.kaylor added a comment to D47925: Add debug info for OProfile porifling support.

Thanks for the patch!

Jun 8 2018, 3:15 PM

Jun 7 2018

andrew.w.kaylor added a reviewer for D47491: Expand constrained FP operations: craig.topper.
Jun 7 2018, 10:50 AM
andrew.w.kaylor added a comment to D47491: Expand constrained FP operations.

I'm adding Craig Topper as a reviewer because he knows the vector selection DAG stuff better than I do. The constrained FP handling looks OK to me.

Jun 7 2018, 10:49 AM

May 21 2018

andrew.w.kaylor added inline comments to D46967: Vector constrained FP intrinsics.
May 21 2018, 5:18 PM
andrew.w.kaylor added a comment to D45576: [RFC] Allow target to handle STRICT floating-point nodes.

The reason that I originally implemented this the way I did, mutating the strict nodes to their non-constrained equivalents, was that I thought it would require too much duplication in the .td files to implement all the pattern matching for the strict nodes. The original plan was to find some other way to communicate the "strict" state to the target after instruction selection, but I never found a way to do that.

May 21 2018, 4:22 PM

May 18 2018

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

At some point we should create a document that describes the entire flow of FP instructions through the instruction selection process. To be honest I don't remember how it all works, and that makes it difficult to review changes like this. It would also be nice to verify that we all have the same understanding of how it works. I don't mean to volunteer you to produce the entire document, but would you mind giving me a rough outline? I'm still concerned about the case that is not chained.

May 18 2018, 4:43 PM

Apr 23 2018

andrew.w.kaylor accepted D45947: [CodeGen] Do not allow opt-bisect-limit to skip ScalarizeMaskedMemIntrin..

lgtm

Apr 23 2018, 9:46 AM

Apr 4 2018

andrew.w.kaylor accepted D44464: allow custom OptBisect classes set to LLVMContext.

Thank you for your patience in addressing my concerns.

Apr 4 2018, 10:02 AM

Apr 3 2018

andrew.w.kaylor added inline comments to D44464: allow custom OptBisect classes set to LLVMContext.
Apr 3 2018, 1:39 PM
andrew.w.kaylor added inline comments to D44464: allow custom OptBisect classes set to LLVMContext.
Apr 3 2018, 12:07 PM

Mar 27 2018

andrew.w.kaylor added inline comments to D44464: allow custom OptBisect classes set to LLVMContext.
Mar 27 2018, 1:30 PM

Mar 26 2018

andrew.w.kaylor added a comment to D44821: [NFC] OptPassGate extracted from OptBisect.

I'm OK with this.

Mar 26 2018, 10:06 AM

Mar 23 2018

andrew.w.kaylor added inline comments to D44821: [NFC] OptPassGate extracted from OptBisect.
Mar 23 2018, 10:39 AM
andrew.w.kaylor added a comment to D44817: Fix a block color copying problem in LICM.

Sigh.
(a quick scan of things named Map in LLVM doesn't find any other obvious cases of this).

I wonder if we shouldn't have a debug/expensive checks mode where it moves all the memory on find and construct to make all these situations fail obviously and instantly so it could be found by bots.

Mar 23 2018, 9:57 AM

Mar 22 2018

andrew.w.kaylor created D44817: Fix a block color copying problem in LICM.
Mar 22 2018, 9:40 PM

Mar 20 2018

andrew.w.kaylor added a comment to D44464: allow custom OptBisect classes set to LLVMContext.

As long as you're OK with the fact that this will probably be replaced in the near future (and please add a comment indicating that above the setOptPassGate function), I'm OK with this being added. I do prefer OptPassGate as a name for the generalized functionality.

Mar 20 2018, 8:01 AM

Mar 19 2018

andrew.w.kaylor added a comment to D44464: allow custom OptBisect classes set to LLVMContext.

I would prefer not to overload the behavior of OptBisect. ...

Andrew, would it be ok to create an NFC extracting a pure virtual class OptPassGate from OptBisect? Then I could make use of the OptPassGate interface to implement context specific pass gates without referring to OptBisect.

Mar 19 2018, 5:14 PM

Mar 15 2018

andrew.w.kaylor added a comment to D44464: allow custom OptBisect classes set to LLVMContext.

I would like to stress that we consider OptBisect to be more than just "bisector", but rather the only
available way of skipping optimization passes with an arbitrarily complex control pattern.

Mar 15 2018, 10:20 AM

Mar 14 2018

andrew.w.kaylor added a comment to D44464: allow custom OptBisect classes set to LLVMContext.

I have some concerns about this patch, mostly centered around what the intended use cases are.

Mar 14 2018, 12:18 PM

Mar 7 2018

andrew.w.kaylor added a comment to D44216: [LangRef] make it clear that FP instructions do not have side effects.

Thanks for taking the initiative on this!

Mar 7 2018, 9:51 AM

Mar 6 2018

andrew.w.kaylor added inline comments to D43515: More math intrinsics for conservative math handling.
Mar 6 2018, 9:14 AM

Feb 28 2018

andrew.w.kaylor added inline comments to D43515: More math intrinsics for conservative math handling.
Feb 28 2018, 11:26 AM

Feb 21 2018

andrew.w.kaylor added inline comments to D43515: More math intrinsics for conservative math handling.
Feb 21 2018, 6:18 PM