andrew.w.kaylor (Andy Kaylor)
User

Projects

User does not belong to any projects.

User Details

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

Recent Activity

Yesterday

andrew.w.kaylor updated subscribers of D31789: [TLI] Add mapping for various '__<func>_finite' forms of the math routines to SVML routines.
Mon, Apr 24, 12:33 PM
andrew.w.kaylor updated subscribers of D31788: [ConstantFolding] Add folding for various math '__<func>_finite' routines generated from -ffast-math.
Mon, Apr 24, 12:32 PM
andrew.w.kaylor updated subscribers of D31787: [TLI] Add declarations for various math header file routines from math-finite.h that create '__<func>_finite as functions.
Mon, Apr 24, 12:32 PM

Fri, Apr 21

andrew.w.kaylor accepted D31182: [InstCombine] fadd double (sitofp x), y check that the promotion is valid .

I'm happy with this. Thanks for the improvements!

Fri, Apr 21, 10:32 AM

Thu, Apr 20

andrew.w.kaylor created D32319: Add constrained intrinsics for some libm-equivalent operations.
Thu, Apr 20, 3:54 PM

Mar 23 2017

andrew.w.kaylor added inline comments to D31182: [InstCombine] fadd double (sitofp x), y check that the promotion is valid .
Mar 23 2017, 3:32 PM

Mar 21 2017

andrew.w.kaylor added inline comments to D31182: [InstCombine] fadd double (sitofp x), y check that the promotion is valid .
Mar 21 2017, 1:07 PM
andrew.w.kaylor added inline comments to D31182: [InstCombine] fadd double (sitofp x), y check that the promotion is valid .
Mar 21 2017, 1:00 PM

Mar 13 2017

andrew.w.kaylor abandoned D30662: Update clang filtering for mxcsr.
Mar 13 2017, 11:50 AM
andrew.w.kaylor abandoned D30661: [x86] Split MXCSR into two pseudo-registers.

It looks like I need to rethink this.

Mar 13 2017, 11:49 AM

Mar 7 2017

andrew.w.kaylor added a comment to D30661: [x86] Split MXCSR into two pseudo-registers.

OK, so maybe that puts me back in the position of needing to find a way to conditionally add the MXCSR use/def information only when the strict semantics are required, in which case there would be no significant advantage to splitting the register as I'm proposing here.

Mar 7 2017, 12:39 PM

Mar 6 2017

andrew.w.kaylor added a comment to D30661: [x86] Split MXCSR into two pseudo-registers.

It's not just DCE which is problematic... we could also sink a floating-point operation past a read from the status register. I suppose you could prevent that particular problem by making reads from the status register write to the control bits, but that causes its own problems.

Mar 6 2017, 10:21 PM
andrew.w.kaylor added a comment to D30661: [x86] Split MXCSR into two pseudo-registers.

A subsequent patch will update floating point operations to add an implicit use of the control bits and an implicit def of the status bits

This seems kind of confusing... strict floating-point ops need to implicitly use and def the status bits, because the new value depends on the previous value. You can think of an FP operation as a logical OR acting on the status register. Many kinds of code motion are legal (e.g. you can reorder FP operations with each other, or hoist them out of loops). But if you omit the use, other optimizations won't work correctly; for example, dead code elimination will eliminate FP operations which have a visible effect on the status register.

Given that, I'm not sure what splitting the status register buys you; I guess it becomes easier to check whether an instruction modifies the control bits?

Mar 6 2017, 4:12 PM
andrew.w.kaylor added a comment to D30662: Update clang filtering for mxcsr.

Is it possible to add a test case (possibly in CodeGen)?

Mar 6 2017, 1:36 PM
andrew.w.kaylor added a dependency for D30662: Update clang filtering for mxcsr: D30661: [x86] Split MXCSR into two pseudo-registers.
Mar 6 2017, 9:44 AM
andrew.w.kaylor added a dependent revision for D30661: [x86] Split MXCSR into two pseudo-registers: D30662: Update clang filtering for mxcsr.
Mar 6 2017, 9:44 AM
andrew.w.kaylor created D30662: Update clang filtering for mxcsr.
Mar 6 2017, 9:44 AM
andrew.w.kaylor created D30661: [x86] Split MXCSR into two pseudo-registers.
Mar 6 2017, 9:41 AM

Feb 13 2017

andrew.w.kaylor created D29903: [X86] Add MXCSR register.
Feb 13 2017, 12:16 PM

Jan 17 2017

andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

Is there anything left blocking this patch?

Jan 17 2017, 11:10 AM

Jan 11 2017

andrew.w.kaylor updated the diff for D27028: Add intrinsics for constrained floating point operations.

-Consolidated examination of StrictFP node opcodes.

Jan 11 2017, 12:47 PM

Jan 10 2017

andrew.w.kaylor updated the diff for D27028: Add intrinsics for constrained floating point operations.

-Combined uses of string literals for FP rounding mode and exception behavior.
-Removed extension to StringSwitch since it is no longer needed.
-Added documentation explaining that the rounding mode argument isn't used from the frem intrinsic.

Jan 10 2017, 5:32 PM

Jan 5 2017

andrew.w.kaylor added a comment to D28363: [LICM] Small update to note changes made in hoistRegion.

(Out of curiosity - you mean r290726 actually has an observable effect on compile time?)

Jan 5 2017, 11:01 AM
andrew.w.kaylor retitled D28363: [LICM] Small update to note changes made in hoistRegion from to [LICM] Small update to note changes made in hoistRegion.
Jan 5 2017, 9:32 AM

Jan 4 2017

andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

When frem has a meaningful result, it is always exact, so perhaps we should omit the rounding behavior argument? I think we still need a constrained frem intrinsic, though, to handle the exceptional behavior in cases such as "frem inf, x" and "frem x, 0".

Jan 4 2017, 5:40 PM

Jan 3 2017

andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

FWIW, rounding controls are needed for llvm.fma.*, llvm.fmuladd.*, and llvm.sqrt.*

Jan 3 2017, 10:59 AM
andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

Ping.

Jan 3 2017, 10:06 AM

Dec 21 2016

andrew.w.kaylor accepted D27965: Update mailing list post URL.

It looks to me like you are probably correct about the intended mailing list post, but it's still not particularly helpful. It would be nice to have a reference to a primary source, but this is the best I could find:

Dec 21 2016, 12:37 PM

Dec 16 2016

andrew.w.kaylor accepted D27508: [CodeGen] Make MachineInstr::isIdenticalTo() symmetric..

I have one nitpick about a typo in a comment, but otherwise this looks good to me.

Dec 16 2016, 10:59 AM

Dec 15 2016

andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

Ping

Dec 15 2016, 2:45 PM
andrew.w.kaylor added a comment to D25848: [PM/OptBisect] Don't crash with some particular values of -opt-bisect-limit=.

I consider this reasonable, but I don't feel qualified enough to review as I'm not a LICM expert, so I'm CC:ing @danielcdh . I'm slightly worried about other passes hitting a similar issue (expecting some state to be freed and asserting in doFinalization())

Dec 15 2016, 2:43 PM
andrew.w.kaylor added a comment to D25848: [PM/OptBisect] Don't crash with some particular values of -opt-bisect-limit=.

What do you think of this change instead?

Index: lib/Transforms/Scalar/LICM.cpp
===================================================================
--- lib/Transforms/Scalar/LICM.cpp	(revision 289480)
+++ lib/Transforms/Scalar/LICM.cpp	(working copy)
@@ -124,8 +124,13 @@
   }
Dec 15 2016, 12:34 PM

Dec 14 2016

andrew.w.kaylor added a comment to D25848: [PM/OptBisect] Don't crash with some particular values of -opt-bisect-limit=.

Sorry this is moving so slowly. I just reproduced the problem with the test file from your last comment. I'll take a closer look and see if I can understand what's going on.

Dec 14 2016, 12:29 PM
andrew.w.kaylor requested changes to D27508: [CodeGen] Make MachineInstr::isIdenticalTo() symmetric..
Dec 14 2016, 12:22 PM

Dec 12 2016

andrew.w.kaylor retitled D27693: [WinEH] Avoid holding references to BlockColor (DenseMap) entries while inserting new elements from to [WinEH] Avoid holding references to BlockColor (DenseMap) entries while inserting new elements.
Dec 12 2016, 5:50 PM

Dec 9 2016

andrew.w.kaylor updated the diff for D27582: Avoid infinite loops in branch folding.

I moved the isEHPad() check, as suggested.

Dec 9 2016, 4:46 PM
andrew.w.kaylor added inline comments to D27582: Avoid infinite loops in branch folding.
Dec 9 2016, 12:03 PM

Dec 8 2016

andrew.w.kaylor updated subscribers of D27028: Add intrinsics for constrained floating point operations.
Dec 8 2016, 11:56 AM
andrew.w.kaylor retitled D27582: Avoid infinite loops in branch folding from to Avoid infinite loops in branch folding.
Dec 8 2016, 11:02 AM

Dec 5 2016

andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

Correct handling of ftz is required for correctness, so it isn't appropriate to be an optimization hint placed with the fast math flags

Dec 5 2016, 5:50 PM
andrew.w.kaylor updated the diff for D27028: Add intrinsics for constrained floating point operations.

Fixed typos and style issues.
Added FIXME comments as requested.

Dec 5 2016, 5:39 PM
andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

Having the llvm_unreachable right after the StringSwitch should achieve the same thing.

I'm not sure I understand what you're suggesting here. If I do this:

return StringSwitch<RoundingMode>(RoundingArg)
  .Case("round.dynamic",    rmDynamic)
  .Case("round.tonearest",  rmToNearest)
  .Case("round.downward",   rmDownward)
  .Case("round.upward",     rmUpward)
  .Case("round.towardzero", rmTowardZero);
llvm_unreachable("Unexpected rounding mode argument in FP intrinsic!");

the llvm_unreachable statement is purely unreachable because the implicit default from StringSwitch will assert or dereference a null pointer. The llvm_unreachable in this case effectively becomes a comment.

Not really: in an optimized build it means that the default case is unreachable. The assertion does not exist there, and the optimizer can drop the nullptr dereference.

Dec 5 2016, 5:30 PM
andrew.w.kaylor added inline comments to D27028: Add intrinsics for constrained floating point operations.
Dec 5 2016, 5:19 PM
andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

Having the llvm_unreachable right after the StringSwitch should achieve the same thing.

Dec 5 2016, 3:43 PM
andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

I see. I still think it's worth adding UnreachableDefault() instead of just a comment explaining that other values will assert/crash. I'm checking the legal values in the verfifier, so this shouldn't be an issue.

Dec 5 2016, 2:51 PM
andrew.w.kaylor added inline comments to D27028: Add intrinsics for constrained floating point operations.
Dec 5 2016, 2:41 PM
andrew.w.kaylor added inline comments to D27028: Add intrinsics for constrained floating point operations.
Dec 5 2016, 12:03 PM
andrew.w.kaylor added inline comments to D27028: Add intrinsics for constrained floating point operations.
Dec 5 2016, 11:08 AM

Nov 28 2016

andrew.w.kaylor updated the diff for D27028: Add intrinsics for constrained floating point operations.

I re-wrote the ISel code to introduce a pseudo-instruction for the strict variants of FP operations, which is mutated directly to a normal FP node just before instruction selection. I removed the SDNodeFlag extensions I had added in my original patch because they aren't needed in this implementation. Some variant of that code will likely need to be re-introduced at some point, particularly to handle FTZ rounding modes.

Nov 28 2016, 1:46 PM

Nov 23 2016

andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

It's not handled in general llvm. We currently have a subtarget feature for f32/f64 denormal support in the default rounding mode

Nov 23 2016, 1:10 PM
andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

Is flush-to-zero currently handled with function attributes?

Nov 23 2016, 12:58 PM
andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

As I mentioned at the meeting I think these need a way to control whether denormals are flushed or not

You mean that there should be a way to control this on a per-operation basis, or there should be some way to represent that the user might be changing some thread state that controls how this is done?

Nov 23 2016, 11:25 AM
andrew.w.kaylor added a comment to D27028: Add intrinsics for constrained floating point operations.

Based on our conversation at the dev meeting, here's how I thought this would work:

  1. Introduce target-independent chain-carrying nodes to represent these operations. For argument's sake, STRICT_FADD, etc.
  2. Since nothing in the SDAG knows about what these nodes do, there's no problem with optimizations doing bad things.
  3. You'd do something minimal in SelectionDAGISel::DoInstructionSelection() around the call to:

    Select(Node);

    so that it would become:

    bool IsStrictFPOp = isStrictFPOp(Node); if (IsStrictFPOp) mutateStrictFPToFP(Node); // STRICT_FADD -> FADD, etc.

    Select(Node);

    if (IsStrictFPOp && !TLI->addStrictFPRegDeps(Node)) report_fatal_error("Could not add strict FP reg deps");

    and then you'd be done. Obviously this is somewhat hand wavy, but if there are complexities I'm overlooking, I'd like to understand them.
Nov 23 2016, 10:49 AM

Nov 22 2016

andrew.w.kaylor retitled D27028: Add intrinsics for constrained floating point operations from to Add intrinsics for constrained floating point operations.
Nov 22 2016, 5:32 PM

Nov 21 2016

andrew.w.kaylor updated the diff for D26485: Add IntrInaccessibleMemOnly property for intrinsics.

Removed IntrInaccessibleMemOnly from llvm.assume.

Nov 21 2016, 5:09 PM
andrew.w.kaylor added a comment to D26485: Add IntrInaccessibleMemOnly property for intrinsics.

Ping.

Nov 21 2016, 11:02 AM

Nov 10 2016

andrew.w.kaylor updated the diff for D26485: Add IntrInaccessibleMemOnly property for intrinsics.

I added the IntrInaccessibleMemOrArgMemOnly property, and updated the llvm.assume intrinsic to use IntrInaccessibleMemOnly.

Nov 10 2016, 10:48 AM

Nov 9 2016

andrew.w.kaylor retitled D26485: Add IntrInaccessibleMemOnly property for intrinsics from to Add IntrInaccessibleMemOnly property for intrinsics.
Nov 9 2016, 4:53 PM

Nov 8 2016

andrew.w.kaylor added a comment to D26382: [BasicAA] Teach BasicAA to handle the inaccessiblememonly and inaccessiblemem_or_argmemonly attributes.

This will work, but we might want a separate tracking state for this (because otherwise we won't be able to infer readonly for any functions with FP operations, which is going to be very unfortunate). We might do this as a later enhancement, however.

Nov 8 2016, 1:26 PM

Nov 7 2016

andrew.w.kaylor retitled D26382: [BasicAA] Teach BasicAA to handle the inaccessiblememonly and inaccessiblemem_or_argmemonly attributes from to [BasicAA] Teach BasicAA to handle the inaccessiblememonly and inaccessiblemem_or_argmemonly attributes.
Nov 7 2016, 6:12 PM

Oct 25 2016

andrew.w.kaylor added a comment to D25848: [PM/OptBisect] Don't crash with some particular values of -opt-bisect-limit=.

I'm trying to understand where the data structured entry gets removed when the pass is not skipped. I tried downloading the reproducer from the PR you mentioned, but I can't seem to get this to happen with that file and the command line you listed above. I have seen this problem before, but I'm having trouble making it happen now.

Oct 25 2016, 4:21 PM
andrew.w.kaylor added inline comments to D25848: [PM/OptBisect] Don't crash with some particular values of -opt-bisect-limit=.
Oct 25 2016, 12:18 PM

Oct 6 2016

andrew.w.kaylor added a comment to D24896: [safestack] Require TargetMachine to be provided..

The problem with adding more run lines is that if I understand this failure correctly, the test would fail if any of the run targets was missing from the build configuration. Long term, I think it would be nice if LIT had a way to selectively disable individual run lines based on the build configuration.

Oct 6 2016, 4:05 PM
andrew.w.kaylor added a comment to D24896: [safestack] Require TargetMachine to be provided..

It looks like the explicit triples are being used in the tests in the non-arch-specific directory simply to force the tests to be run for both x86-64 and i386 targets. This is great for x86, but it means that these tests aren't run at all against other targets, even when another target is the default for the build. That seems bad.

Oct 6 2016, 2:22 PM

Sep 27 2016

andrew.w.kaylor closed D16883: Fix build LLVM with -D LLVM_USE_INTEL_JITEVENTS:BOOL=ON.
Sep 27 2016, 6:56 AM

Sep 26 2016

andrew.w.kaylor added a comment to D19513: Add optimization bisect opt-in calls for Mips passes.

I apologize for the delay. I forgot about this patch. I'll get it committed today.

Sep 26 2016, 10:45 AM

Aug 18 2016

andrew.w.kaylor retitled D23683: Include X86CallFrameOptimization in the opt-bisect process from to Include X86CallFrameOptimization in the opt-bisect process.
Aug 18 2016, 11:40 AM

Jul 26 2016

andrew.w.kaylor retitled D22839: Revert EH-specific branch folding changes to avoid compilation slow down from to Revert EH-specific branch folding changes to avoid compilation slow down.
Jul 26 2016, 5:36 PM

Jul 13 2016

andrew.w.kaylor added a comment to D14996: [WinEH] Avoid infinite loop in BranchFolding for multiple single block funclets.

Any news on this?

Jul 13 2016, 6:05 PM
andrew.w.kaylor accepted D14900: [mips] SelectionDAGISel subclasses now follow the optimization level..

LGTM

Jul 13 2016, 10:52 AM

Jul 6 2016

andrew.w.kaylor updated the diff for D21143: Include SelectionDAGISel in the opt-bisect process.

Adding a test.

Jul 6 2016, 5:47 PM
andrew.w.kaylor added a comment to D14996: [WinEH] Avoid infinite loop in BranchFolding for multiple single block funclets.

The purpose of this change was to avoid a case where the old algorithm was getting into an infinite loop moving different blocks to the end of the function. As I recall, this situation arose because the old code was sometimes mistakenly deciding that control flow could fall through from a normal block to an EH block that was reachable from that block via an exception. If multiple EH blocks were reachable, the old code wanted to place each of them immediately after the block from which they were reached.

Jul 6 2016, 2:00 PM

Jun 8 2016

andrew.w.kaylor retitled D21143: Include SelectionDAGISel in the opt-bisect process from to Include SelectionDAGISel in the opt-bisect process.
Jun 8 2016, 10:43 AM

Jun 7 2016

andrew.w.kaylor added a comment to D20984: add control flags to LICM.

I was trying to completely disable LICM for perf analysis, not bisecting a correctness problem with LICM.

Jun 7 2016, 10:06 AM

Jun 6 2016

andrew.w.kaylor added a comment to D20984: add control flags to LICM.

You definitely could (and I think should) do this with opt-bisect.

Jun 6 2016, 10:47 AM

May 26 2016

andrew.w.kaylor updated the diff for D20453: Remove optnone/opt-bisect check from StackColoring.

Implemented suggested revisions.

May 26 2016, 4:56 PM
andrew.w.kaylor added a comment to D20453: Remove optnone/opt-bisect check from StackColoring.

Sounds good to me. I'll upload changes for final review as soon as my local testing finishes. It looks like I still need to take that line out of the optnone-llc test because the pass aborts for other reasons before calling skipFunction. Otherwise, this looks like a very clean solution.

May 26 2016, 4:53 PM
andrew.w.kaylor added a reviewer for D20453: Remove optnone/opt-bisect check from StackColoring: thanm.
May 26 2016, 3:27 PM
andrew.w.kaylor added a comment to D20453: Remove optnone/opt-bisect check from StackColoring.

Hmmm. In the optnone case, presumably we're not running that pass that inserts the lifetime markers; if there are no markers, and this pass runs, naively it looks like this would be a no-op pass. So, from the optnone perspective, this change would not be a problem.

But if you're bisecting, there might be markers, and if the bisection point is between the insertion and this pass, then later on codegen will fail. This change means, if the bisection point is between the insertion and this pass, then this pass runs anyway.

In effect this becomes an always-run pass, and whether it does anything depends on whether the marker-insertion pass runs. Makes the bisection less ideal, but I guess we can live with that.

May 26 2016, 3:27 PM

May 23 2016

andrew.w.kaylor updated the diff for D19640: Update opt-bisect code to avoid skipping AlwaysInliner.

Refactored implementation as suggested.

May 23 2016, 11:10 AM
andrew.w.kaylor added a comment to D19640: Update opt-bisect code to avoid skipping AlwaysInliner.

I think we can achieve this without a virtual function by refactoring all the code inside Inliner::runOnScc() that comes below the skipSCC() check into an own function. The AlwaysInliner pass can then just override runOnSCC() which calls this common function but contrary to Inliner::runOnSCC() without checking skipSCC().

May 23 2016, 9:37 AM

May 19 2016

andrew.w.kaylor retitled D20453: Remove optnone/opt-bisect check from StackColoring from to Remove optnone/opt-bisect check from StackColoring.
May 19 2016, 3:55 PM

May 18 2016

andrew.w.kaylor accepted D20377: [MBP] Remove a redundant skipFunction(). NFC..

lgtm

May 18 2016, 1:19 PM

May 3 2016

andrew.w.kaylor added inline comments to D19882: Add opt-bisect support to additional passes that can be skipped.
May 3 2016, 2:38 PM
andrew.w.kaylor retitled D19882: Add opt-bisect support to additional passes that can be skipped from to Add opt-bisect support to additional passes that can be skipped.
May 3 2016, 11:22 AM
andrew.w.kaylor added a comment to D19513: Add optimization bisect opt-in calls for Mips passes.

Ping

May 3 2016, 11:04 AM

Apr 27 2016

andrew.w.kaylor retitled D19640: Update opt-bisect code to avoid skipping AlwaysInliner from to Update opt-bisect code to avoid skipping AlwaysInliner.
Apr 27 2016, 5:00 PM

Apr 26 2016

andrew.w.kaylor updated the diff for D19554: Add optimization bisect opt-in calls for PowerPC passes.

Added code to check of opt level != None before adding the PPCVSXFMAMutate pass
Made the PPCVSXFMAMutate pass skippable

Apr 26 2016, 6:01 PM
andrew.w.kaylor added a comment to D19554: Add optimization bisect opt-in calls for PowerPC passes.

PPCVSXFMAMutate is an optimization, and should be included in the skippable passes.

Apr 26 2016, 3:09 PM
andrew.w.kaylor retitled D19562: Add optimization bisect opt-in calls for SystemZ passes from to Add optimization bisect opt-in calls for SystemZ passes.
Apr 26 2016, 2:58 PM
andrew.w.kaylor retitled D19554: Add optimization bisect opt-in calls for PowerPC passes from to Add optimization bisect opt-in calls for PowerPC passes.
Apr 26 2016, 1:00 PM
andrew.w.kaylor updated the diff for D19518: Add optimization bisect opt-in calls for NVPTX passes.

Removed skip check for NVPTXLowerKernelArgs

Apr 26 2016, 12:44 PM
andrew.w.kaylor added inline comments to D19518: Add optimization bisect opt-in calls for NVPTX passes.
Apr 26 2016, 11:57 AM
andrew.w.kaylor added a comment to D19518: Add optimization bisect opt-in calls for NVPTX passes.

Oh, I see what you mean now.

So NVPTXPeephole should be guarded by CodeGenOpt::None and thus is safe to skip.

Apr 26 2016, 11:48 AM
andrew.w.kaylor updated the diff for D19439: Optimization bisect support in X86-specific passes.

Removed skip calls from passes that are run at -O0
Moved skip checks behind other single variable conditions

Apr 26 2016, 10:45 AM
andrew.w.kaylor added a comment to D19439: Optimization bisect support in X86-specific passes.

My comments about vzeroupper make me wonder whether we want skipFunction to be able to make the distinction between skipping a pass for OptBisect and skipping a pass for -O0. I can certainly imagine wanting to run some functionally optional "optimization" passes at -O0, e.g. a pass that can improve the size/performance of the generated code w/o negatively affecting debuggability.

Apr 26 2016, 10:18 AM

Apr 25 2016

andrew.w.kaylor retitled D19518: Add optimization bisect opt-in calls for NVPTX passes from to Add optimization bisect opt-in calls for NVPTX passes.
Apr 25 2016, 6:09 PM
andrew.w.kaylor added inline comments to D19449: Add optimization bisect opt-in calls for ARM passes.
Apr 25 2016, 6:01 PM
andrew.w.kaylor retitled D19513: Add optimization bisect opt-in calls for Mips passes from to Add optimization bisect opt-in calls for Mips passes.
Apr 25 2016, 4:53 PM
andrew.w.kaylor retitled D19509: Add optimization bisect opt-in calls for Hexagon passes from to Add optimization bisect opt-in calls for Hexagon passes.
Apr 25 2016, 4:10 PM