Page MenuHomePhabricator

hfinkel (Hal Finkel)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 16 2012, 6:02 PM (322 w, 1 d)

Recent Activity

Thu, Jan 17

hfinkel accepted D56838: [CGP] Check for existing inttotpr before creating new one.

Can we run EarlyCSE after CGP (instead of trying to do these kinds of point fixes)?

Hi Hal,

Thank you for looking into this!

That's a great suggestion! Originally I just eyeballed it as too expensive compile-time wise for the little effect that is achieved here.

This time around with you pointing it out, I performed the actual measurements for a very large suite of shaders (the downstream target in question is a GPU). I see about 1.0 (+/-0.3)% increase in overall compile time (the part of it that happens at an application run-time) on average. The generated code quality improvement that comes out of this may be important, but it doesn't trigger often enough to justify 1% compile time increase across the board.

Thanks,
Roman

Thu, Jan 17, 7:27 PM
hfinkel added a comment to D56867: [ValueTracking] Early out of isValidAssumeForContext if the assume and the context instruction are the same.

If we're going to do anything here, I'd prefer to change it to true, since that's the right answer... it seems like it isn't doing any harm in the meantime.

Thu, Jan 17, 3:53 PM
hfinkel accepted D53928: Enable builtins necessary for SLEEF [AArch64] vectorized trigonometry libm functions.

Please, in the future, make sure you post full-context patches.

Thu, Jan 17, 9:43 AM
hfinkel added a comment to D56838: [CGP] Check for existing inttotpr before creating new one.

Can we run EarlyCSE after CGP (instead of trying to do these kinds of point fixes)?

Thu, Jan 17, 7:30 AM

Fri, Jan 11

hfinkel accepted D56551: [LoopVectorizer] give more advice in remark about failure to vectorize call.

LGTM

Fri, Jan 11, 8:38 AM

Thu, Jan 10

hfinkel added inline comments to D56551: [LoopVectorizer] give more advice in remark about failure to vectorize call.
Thu, Jan 10, 6:05 PM

Wed, Jan 9

hfinkel accepted D56486: [CodeGen] Ignore return sext/zext attributes of unused results for tail calls.

LGTM

Wed, Jan 9, 9:20 AM

Mon, Jan 7

hfinkel accepted D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.
Mon, Jan 7, 9:42 AM
hfinkel accepted D56362: [DemandedBits] Use SetVector for Worklist.

LGTM

Mon, Jan 7, 9:22 AM

Fri, Jan 4

hfinkel added inline comments to D55758: [TableGen] : Extend !if semantics through new language feature !ifs.
Fri, Jan 4, 1:22 PM
hfinkel accepted D56247: [BDCE] Remove dead uses of arguments.

LGTM

Fri, Jan 4, 10:52 AM
hfinkel added a comment to D38501: [ValueTracking] Fix a misuse of APInt in GetPointerBaseWithConstantOffset.

Thanks! Do you need someone to commit the change on your behalf?

Fri, Jan 4, 5:57 AM

Wed, Jan 2

hfinkel committed rL350220: [BasicAA] Support arbitrary pointer sizes (and fix an overflow bug).
[BasicAA] Support arbitrary pointer sizes (and fix an overflow bug)
Wed, Jan 2, 8:31 AM
hfinkel closed D38662: [BasicAA] Support arbitrary pointer sizes (and fix an overflow bug).
Wed, Jan 2, 8:31 AM

Tue, Jan 1

hfinkel accepted D56185: [BDCE] Remove instructions without demanded bits.

LGTM

Tue, Jan 1, 10:03 AM

Mon, Dec 31

hfinkel added a comment to D55563: [BDCE][DemandedBits] Detect dead uses of undead instructions.

Fix removal of dead uses. The previous version had a check whether the previous demanded bits are empty and only dropped the use from the DeadUses set in that case. The motivation for this was that the use could only be part of DeadUses if the demanded bits are empty, so we can save a redundant hash lookup. Of course, this is not actually true, because the previous demanded bits are for the instruction across all users, which is a superset of the demanded bits for a single use. (That being kind of the whole point of this change, I'm really not sure what I was thinking there...)

So now I'm just always doing the erase() call when a use has non-empty demanded bits. I've also added a testcase that was miscompiled with the previous version. I believe that this is also what caused the failure in enc-3des from the test-suite.

Mon, Dec 31, 9:00 AM

Sun, Dec 30

hfinkel added inline comments to D42590: [PowerPC] Try to move the stack pointer update instruction later in the prologue and earlier in the epilogue (Version 2).
Sun, Dec 30, 5:21 PM
hfinkel added inline comments to D42590: [PowerPC] Try to move the stack pointer update instruction later in the prologue and earlier in the epilogue (Version 2).
Sun, Dec 30, 8:58 AM
hfinkel added inline comments to D56156: [DAGCombiner][X86][PowerPC] Teach visitSIGN_EXTEND_INREG to fold (sext_in_reg (aext/sext x)) -> (sext x) when x has more than 1 sign bit and the sext_inreg is from one of them..
Sun, Dec 30, 7:32 AM

Sat, Dec 29

hfinkel added a comment to D56148: [PowerPC] Fix machine verify pass error for PATCHPOINT pseudo instruction that bad machine code.

So this rell-request

Sat, Dec 29, 8:35 AM

Fri, Dec 28

hfinkel accepted D56119: [PowerPC] Fix ADDE, SUBE do not know how to promote operator.
Fri, Dec 28, 6:37 AM

Thu, Dec 27

hfinkel accepted D49076: [PowerPC] handle ISD:TRUNCATE in BitPermutationSelector.

LGTM

Thu, Dec 27, 10:14 PM
hfinkel accepted D55806: [PowerPC] fix register class after converting X-FORM instruction to D-FORM instruction.

LGTM

Thu, Dec 27, 3:39 PM
hfinkel accepted D56078: [PowerPC] Remove the implicit use of the register if it is replaced by Imm.

LGTM

Thu, Dec 27, 9:23 AM
hfinkel added inline comments to D55686: [PowerPC] Fix assert from machine verify pass that unmatched register class about fcmp selection in fast-isel.
Thu, Dec 27, 9:12 AM
hfinkel accepted D56077: [PowerPC] Fix assert from machine verify pass that atomic pseudo expanding causes mismatched register class.

Please fixup the comments, but LGTM.

Thu, Dec 27, 9:09 AM

Fri, Dec 21

hfinkel added a comment to D54498: AbstractCallSite -- A unified interface for (in)direct and callback calls.

I can certainly split this into more patches if that is preferred. I'm unsure though how to test the metadata and abstract call sites without a user.

Fri, Dec 21, 2:21 PM
hfinkel added a comment to D54498: AbstractCallSite -- A unified interface for (in)direct and callback calls.

A high level strategy comment. I think you're trying to go a bit too far in one patch. I'd advise first writing a patch which does nothing but implement the IPConstProp adjustments "the hard way" (i.e. without the AbstractCallSite) and focus on defining the metadata with the semantics you once. To really justify the complexity of the abstraction, you need more than one user. You could add another user to this patch, but doing so will just slow down the review. Separating this into a series of patches (IPConstProp w/metadata def, second user, then introduce abstraction) will make it much easier to see the necessity and make each piece more easily reviewable.

Fri, Dec 21, 10:36 AM
hfinkel added a comment to D55977: [PowerPC] Fix the bug of ISD::ADDE to set its second return type to glue.

LGTM

Fri, Dec 21, 9:37 AM
hfinkel accepted D55977: [PowerPC] Fix the bug of ISD::ADDE to set its second return type to glue.

LGTM

Fri, Dec 21, 9:35 AM
hfinkel accepted D55996: [PowerPC] Fix CR Bit spill pseudo expansion.

LGTM. This certainly looks like a better solution; the previous code was indeed trying to make sure that the containing CR field was defined before the mfocrf. Thanks!

Fri, Dec 21, 8:39 AM

Dec 20 2018

hfinkel accepted D55969: [BasicAA] Fix AA bug on dynamic allocas and stackrestore.

LGTM

Dec 20 2018, 7:19 PM
hfinkel added a comment to D49084: FileCheck: Add support for numeric variables and expressions.

Thanks for updating this patch. It will be very useful!

Dec 20 2018, 7:13 PM
hfinkel added inline comments to D55928: [OpenMP] Add flag for preventing the extension to 64 bits for the collapse loop counter.
Dec 20 2018, 8:26 AM

Dec 19 2018

hfinkel accepted D38662: [BasicAA] Support arbitrary pointer sizes (and fix an overflow bug).

hey @efriedma - @hfinkel and I are wondering if you have any comments on this updated revision of BasicAA improvements. Thanks!

Dec 19 2018, 12:43 PM
hfinkel accepted D52116: Introduce llvm.loop.parallel_accesses and llvm.access.group metadata..

Aside from the requested renaming (see below), this LGTM.

Dec 19 2018, 12:38 PM
hfinkel accepted D55563: [BDCE][DemandedBits] Detect dead uses of undead instructions.
Dec 19 2018, 8:11 AM
hfinkel accepted D55754: [PowerPC] Implement the ”isSelectSupported()“ target hook.

LGTM too.

Dec 19 2018, 7:39 AM

Dec 18 2018

hfinkel accepted D52117: Generate llvm.loop.parallel_accesses instead of llvm.mem.parallel_loop_access metadata..

Minor typo noted below, but otherwise, LGTM (to avoid any misunderstanding: this should be committed after the LLVM change lands).

Dec 18 2018, 5:38 PM
hfinkel added inline comments to D52116: Introduce llvm.loop.parallel_accesses and llvm.access.group metadata..
Dec 18 2018, 5:32 PM
hfinkel added a comment to D53184: [LangRef] Clarify semantics of volatile operations..

Yes, volatile loads and stores access the "same" state as inaccessiblememonly functions, I think.

Dec 18 2018, 4:42 PM
hfinkel added inline comments to D55758: [TableGen] : Extend !if semantics through new language feature !ifs.
Dec 18 2018, 4:10 PM
hfinkel added inline comments to D55563: [BDCE][DemandedBits] Detect dead uses of undead instructions.
Dec 18 2018, 4:03 PM
hfinkel added a comment to D55461: [PowerPC] Update Vector Costs for P9.

Also, cost model changes can be tested directly. See tests in test/Analysis/CostModel/PowerPC/

Dec 18 2018, 3:45 PM
hfinkel added a comment to D55461: [PowerPC] Update Vector Costs for P9.

The calculation the loop vectorizer is making is comparing vector cost / vector factor to scalar cost. The calculation the SLP vectorizer is making is comparing vector cost to scalar cost * vector factor. In either case the vector factor is involved, and once the vector factor is involved it is really a throughput calculation and not a latency calculation. I don't think vectorization can make sense as a latency calculation - the scalar ops are always going to be at least as cheap. The win is in doing more at the same time, not in delivering a particular result faster.

Thanks for explaining. I am not familiar with SLP enough, maybe @hfinkel can help to see whether it is reasonable to consider execution unit num in vectorizer's cost model. Thanks!

Dec 18 2018, 3:45 PM
hfinkel added a comment to D53184: [LangRef] Clarify semantics of volatile operations..

I can add a sentence to specifically state that this can modify state accessed by functions marked with the inaccessiblememonly attribute, and vice versa, if that's the interaction you're worried about. (I don't think it's practical to have multiple forms of inaccessible state.)

Dec 18 2018, 3:02 PM
hfinkel added a comment to D54742: [CodeMetrics] Don't let extends of i1 be free..
Dec 18 2018, 1:14 PM

Dec 17 2018

hfinkel accepted D55785: [LoopVectorize] Rename pass options. NFC..

LGTM. Thanks, I think this naming is more accurate and useful.

Dec 17 2018, 12:54 PM
hfinkel accepted D55716: [LoopUnroll] Honor '#pragma unroll' even with -fno-unroll-loops..

LGTM

Dec 17 2018, 12:17 PM
hfinkel added inline comments to D55710: add pragmas to control Software Pipelining optimisation.
Dec 17 2018, 11:27 AM
hfinkel added a comment to D55716: [LoopUnroll] Honor '#pragma unroll' even with -fno-unroll-loops..

Such explicit transformations should take precedence over disabling heuristics.

Dec 17 2018, 8:48 AM

Dec 14 2018

hfinkel added a reviewer for D55710: add pragmas to control Software Pipelining optimisation: Meinersbur.
Dec 14 2018, 10:17 AM
hfinkel accepted D55666: [Transforms] Preserve metadata when converting invoke to call..

I think that this is okay. There's no semantic change nor a change in control dependence. For this to cause a problem, there would need to be metadata that would change meaning or validity when the instruction changes from an invoke to a call (where the invoke is semantically equivalent to the call).

Dec 14 2018, 8:20 AM
hfinkel accepted D55690: [TransformWarning] Do not warn missed transformations in optnone functions..

LGTM

Dec 14 2018, 8:10 AM

Dec 13 2018

hfinkel added inline comments to D55666: [Transforms] Preserve metadata when converting invoke to call..
Dec 13 2018, 8:12 PM
hfinkel added a comment to D55679: Place .text.hot section before .text..

Care to update the title of this review? ;)

Dec 13 2018, 4:30 PM

Dec 10 2018

hfinkel added a comment to D54412: [RFC] Re-implementing -fveclib with OpenMP.

I see. I am happy to create a new one if that is a requirement for the RFC submission. One question:

how do I make sure it goes to the lists? I thought I did it and I want to avoid making the same error.

By setting correct "repo" field (best) and/or adding the appropriate -commits list as the subscriber.

Sure. Can you specify exactly which are the repo fields I have to set? Sorry, it is not cleat to me from the changes you have done here.

Moreover, I can see though that you have subscribed llvm-commits. Is that the only one I need to add to the reviewers field? No cfe-commits list?

Dec 10 2018, 9:55 AM

Dec 7 2018

hfinkel accepted D55297: [DemandedBits][BDCE] Support vectors of integers.

LGTM

Dec 7 2018, 6:34 AM

Dec 6 2018

hfinkel accepted D55408: [PowerPC] Fix assert from machine verify pass that missing undef register flag.

@hfinkel could you please have a look since the last change is related to your part.

Dec 6 2018, 9:01 PM
hfinkel accepted D55297: [DemandedBits][BDCE] Support vectors of integers.

This LGTM. However, please, in llvm/Analysis/DemandedBits.h, document what this means for vectors (that it treats all elements the same and returns a mask of the scalar size). You might expand on the comment:

Dec 6 2018, 10:40 AM

Dec 5 2018

hfinkel added inline comments to D55297: [DemandedBits][BDCE] Support vectors of integers.
Dec 5 2018, 4:09 PM
hfinkel added inline comments to D55290: [docs] Update llvm.loop metadata documentation..
Dec 5 2018, 9:59 AM

Dec 4 2018

hfinkel added a comment to D54966: Implement P1007R3 `std::assume_aligned`.

@chandlerc, @hfinkel: does an attribute-only implementation (with no constant evaluation enforcement) materially hurt the ability for the optimizer to use this annotation? Eg, in:

extern char k[16];
void f() {
  // the initializer of p is a constant expression and might get constant-folded to &k by the frontend
  char *p = std::assume_aligned<16>(&k);
  // ...do stuff...
}

the alignment assumption may well never be emitted as IR. Is that acceptable?

__attribute__((assume_aligned(N))) and __builtin_assume_aligned are, at the IR level, implemented in a very-similar way. For functions with that attribute on the return type, we essentially emit an alignment assumption on the return value at every call site (in CodeGenFunction::EmitCall). Thus, from the optimizer's perspective, I don't think that it makes a big difference.

The point here is that you may well get no IR annotation whatsoever for the above call, because the frontend might constant-evaluate the initializer of p down to just &k, and then emit IR that just initializes p to &k with no alignment assumption. Whereas if we treated assume_aligned<N>(p) as non-constant in the cases where we cannot prove that p is suitably aligned (as __builtin_assume_aligned does), then we would emit IR for the alignment assumption, but the downside is that the initializer of p would no longer be a constant expression.

Essentially, what I'm trying to gauge here is, is it OK that you probably don't actually get an alignment assumption in a function like the f() above, because it will probably be constant-evaluated away to nothing? Or do we need the constant evaluator to have some kind of side-channel by which it can communicate back to the code generator that an alignment assumption should be applied to k?

Dec 4 2018, 3:34 PM
hfinkel added inline comments to D54653: Remove branch from CreateAlignmentAssumption.
Dec 4 2018, 2:48 PM
hfinkel added inline comments to D55290: [docs] Update llvm.loop metadata documentation..
Dec 4 2018, 1:17 PM
hfinkel added inline comments to D55290: [docs] Update llvm.loop metadata documentation..
Dec 4 2018, 12:34 PM
hfinkel added inline comments to D54653: Remove branch from CreateAlignmentAssumption.
Dec 4 2018, 10:07 AM
hfinkel added inline comments to D54653: Remove branch from CreateAlignmentAssumption.
Dec 4 2018, 9:29 AM
hfinkel added inline comments to D54653: Remove branch from CreateAlignmentAssumption.
Dec 4 2018, 9:25 AM
hfinkel added inline comments to D52116: Introduce llvm.loop.parallel_accesses and llvm.access.group metadata..
Dec 4 2018, 8:03 AM
hfinkel added inline comments to D49281: [Unroll/UnrollAndJam/Vectorizer/Distribute] Add followup loop attributes..
Dec 4 2018, 7:49 AM

Dec 3 2018

hfinkel added inline comments to D54498: AbstractCallSite -- A unified interface for (in)direct and callback calls.
Dec 3 2018, 5:52 PM
hfinkel added a comment to D54966: Implement P1007R3 `std::assume_aligned`.

We don't need to use __builtin_assume_aligned to implement this. We can use __attribute__((assume_aligned(N))) instead. That solves our constexpr problem.

...

@chandlerc, @hfinkel: does an attribute-only implementation (with no constant evaluation enforcement) materially hurt the ability for the optimizer to use this annotation? Eg, in:

extern char k[16];
void f() {
  // the initializer of p is a constant expression and might get constant-folded to &k by the frontend
  char *p = std::assume_aligned<16>(&k);
  // ...do stuff...
}

the alignment assumption may well never be emitted as IR. Is that acceptable?

Dec 3 2018, 5:31 PM
hfinkel added inline comments to D54653: Remove branch from CreateAlignmentAssumption.
Dec 3 2018, 5:23 PM
hfinkel added inline comments to D52117: Generate llvm.loop.parallel_accesses instead of llvm.mem.parallel_loop_access metadata..
Dec 3 2018, 4:55 PM
hfinkel added a comment to D52116: Introduce llvm.loop.parallel_accesses and llvm.access.group metadata..
Dec 3 2018, 4:43 PM
hfinkel accepted D49281: [Unroll/UnrollAndJam/Vectorizer/Distribute] Add followup loop attributes..

A few additional comments. Otherwise, this LGTM. When @dmgreen is happy with the unrolling changes, I think you're good to go.

Dec 3 2018, 4:32 PM

Dec 1 2018

hfinkel added inline comments to D54653: Remove branch from CreateAlignmentAssumption.
Dec 1 2018, 3:59 PM

Nov 29 2018

hfinkel accepted D55103: Update relicensing status..

LGTM

Nov 29 2018, 8:27 PM
hfinkel accepted D55042: Introduce MaxUsesToExplore argument to capture tracking.

LGTM

Nov 29 2018, 11:32 AM

Nov 28 2018

hfinkel added a comment to D55042: Introduce MaxUsesToExplore argument to capture tracking.

Can you please upload the patch with full context?

Nov 28 2018, 7:46 PM

Nov 26 2018

hfinkel accepted D54588: [llvm][IRBuilder] Introspection for CreateAlignmentAssumption*() functions.

LGTM

Nov 26 2018, 7:23 PM

Nov 22 2018

hfinkel added a comment to D53342: [SimplifyLibCalls] Mark known arguments with nonnull.

I have no idea how to fix Clang side :/

Nov 22 2018, 6:20 AM

Nov 21 2018

hfinkel added a comment to D53342: [SimplifyLibCalls] Mark known arguments with nonnull.

Ping :)

Nov 21 2018, 4:48 PM

Nov 20 2018

hfinkel added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.
In D53157#1304275, @kpn wrote:

If we all agree upon that, then we simply have to treat the functions that modify the FPEnv, e.g. fesetexcept(...), as barriers. That way it does not matter if a FENV_ACCESS=OFF function is translated with constrained intrinsics or not, since nothing can be scheduled around these barriers.

I thought we couldn't do barriers. No barriers means no way to prevent code motion and mixing of constrained with non-constrained FP. That was the reason for having all FP in a function be constrained if any of it was.

I'd like to hear more about this. The fesetexcept(...) function and friends change the FPEnv state, which can change the semantics for the instructions that follow. They definitely have to act as a barrier.

Nov 20 2018, 4:49 PM

Nov 19 2018

hfinkel added a comment to D54412: [RFC] Re-implementing -fveclib with OpenMP.

If not, we can go with the #pragma clang declare simd directive, with clang being ifdef guarded to become omp when _OPENMP is detected.

Nov 19 2018, 5:56 PM
hfinkel added a comment to D54412: [RFC] Re-implementing -fveclib with OpenMP.

An alternative might be to enable OpenMP simd parsing by default?

Yes, I thisnk this is doable, to have #pragma omp declare simd and #pragma omp declare variant (only the simd case) enabled by default.

Are you happy for me to modify the RFC with this?

I'm fine with that.

I'm not totally aligned here, but I'm fine proceeding with the RFC revision along this line. I'll wait for more voices to be raised (or not) on the issue. Please keep a note saying that there is a concern raised and those who care should voice their concerns.

Nov 19 2018, 10:47 AM
hfinkel added a comment to D54412: [RFC] Re-implementing -fveclib with OpenMP.

@hsaito , @hfinkel

I would avoid having a clang-specific pragma. By just using the OpenMP one, we provide the library vendors with a mechanism that is based on a standard and therefore can be used by any compiler.

Specifically:

An alternative might be to enable OpenMP simd parsing by default?

Yes, I thisnk this is doable, to have #pragma omp declare simd and #pragma omp declare variant (only the simd case) enabled by default.

Are you happy for me to modify the RFC with this?

Nov 19 2018, 9:04 AM

Nov 18 2018

hfinkel added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

Just because FENV_ACCESS can be toggled on that granularity doesn't mean we have to represent it that way. We've previously agreed (I think) that if FENV_ACCESS is enabled anywhere in a function we will want to use the constrained intrinsics for all FP operations in the function, not just the ones in the scope where it was specified.

Yes, this is also my understanding. We can't soundly mix the two in the same function because we can't prevent the code motion within the function.

Ugh, I don't know. The C Standard's language is so vague.

Nov 18 2018, 8:20 AM

Nov 16 2018

hfinkel added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

Fair enough. Just for conversation's sake, I was envisioning the FE support a little differently...

  1. Add a command line option, say -ffpe_safe=[true|false], that toggles FPEnv-safe code generation for a whole file. A -ffpe_safe=true would be equivalent to FENV_ACCESS=ON at the beginning of a translation unit and we would capture it in some FE variable. That command line option can be overridden by the FENV_ACCESS pragma.
Nov 16 2018, 8:24 PM
hfinkel 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.

Craig's right about not wanting to bloat the inlinable functions in IRBuilder, but this is something that we can measure. In addition, we might be able to move the "slow path" (which create the constrained intrinsics) to the .cpp file (by manually outlining to a different function).

Nov 16 2018, 8:16 PM
hfinkel added a comment to D53157: Teach the IRBuilder about constrained fadd and friends.

Just because FENV_ACCESS can be toggled on that granularity doesn't mean we have to represent it that way. We've previously agreed (I think) that if FENV_ACCESS is enabled anywhere in a function we will want to use the constrained intrinsics for all FP operations in the function, not just the ones in the scope where it was specified.

Nov 16 2018, 8:14 PM
hfinkel 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 16 2018, 8:12 PM
hfinkel requested changes to D54653: Remove branch from CreateAlignmentAssumption.
Nov 16 2018, 8:07 PM
hfinkel added a comment to D54654: Correct CreateAlignmentAssumption to check sign and power-of-2 (Clang Part).

As discussed on IRC, check sign/power of 2 correctly for the alignment assumptions.

Nov 16 2018, 8:02 PM
hfinkel added inline comments to D54412: [RFC] Re-implementing -fveclib with OpenMP.
Nov 16 2018, 7:57 PM
hfinkel added inline comments to D54412: [RFC] Re-implementing -fveclib with OpenMP.
Nov 16 2018, 12:06 PM
hfinkel added inline comments to D54588: [llvm][IRBuilder] Introspection for CreateAlignmentAssumption*() functions.
Nov 16 2018, 11:35 AM
hfinkel added inline comments to D54412: [RFC] Re-implementing -fveclib with OpenMP.
Nov 16 2018, 11:00 AM
hfinkel added inline comments to D54588: [llvm][IRBuilder] Introspection for CreateAlignmentAssumption*() functions.
Nov 16 2018, 10:27 AM