aemerson (Amara Emerson)
Asian George Costanza

Projects

User does not belong to any projects.

User Details

User Since
Sep 9 2013, 3:45 AM (271 w, 2 d)

Compilers at a fruit company

Recent Activity

Thu, Nov 15

aemerson added a comment to D54174: [GlobalISel] LegalizationArtifactCombiner: Combine aext([asz]ext x) -> [asz]ext x.

So these extends are created by the legalizer, correct? If so, it seems ok to me as that's what these artifact combines were intended for.

Thu, Nov 15, 7:14 AM

Mon, Nov 5

aemerson updated the diff for D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.

Added comment for G_BUILD_VECTOR_TRUNC and tests for the verifier. I haven't added all the different combinations because we can only write one test per file, so I tested the most useful of the verifier errors.

Mon, Nov 5, 4:38 PM
aemerson added inline comments to D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.
Mon, Nov 5, 9:56 AM
aemerson updated the diff for D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.

Updated patch to introduce a separate G_BUILD_VECTOR_TRUNC opcode.

Mon, Nov 5, 9:43 AM

Fri, Nov 2

aemerson added a comment to D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.

I'm not sure how this is any better. If we had an opcode G_BUILD_VECTOR_TRUNC, it would have a superset of the functionality of the G_BUILD_VECTOR. You'd still have this powerful opcode, except now you have potential code duplication in handling the two, as well as a hindered G_BUILD_VECTOR.

Unless you're say that G_BUILD_VECTOR _TRUNC can *only* deal with oversize scalars, in which case it's an odd opcode for a corner case (and I would suggest here that we just deal with the inconvenient types, but I'm not married to the idea).

I was suggesting the later.

Generally speaking, I am not a fan of implicit stuff, thus the proposal (and that's easy to have a isBuildVectorLike or something). That said, I'd like to go back as why we need to do that.

So the problem was that we wanted to represent:
a(<4 x s32>) = G_BUILD_VECTOR p(s32), q, r, s
b(<4 x s8>) = G_TRUNC a

into
b(< 4 x s8>) = G_BUILD_VECTOR p(s32), q, r, s

Why can't we keep the "verbose" representation?
I would expect it would be easy to handle that in ISel.

As long as <4 x s32> = the G_BUILD_VECTOR could be legalized I think the worst that will happen is that we just get poor codegen.

Also, just throwing that here, I haven't really thought about it: should we rethink our legality model to check patterns instead of one instruction at a time?
I.e., maybe

a(s8) = ...

is not legal but

a(s8) = ...
b(<4 x s8>) = build_vector a(s8)

is.

I think the issue of sequences becoming illegal because of things like copies being introduced is still a deal breaker for that, and it would also introduce a code motion barrier since we can't select sequences spanning blocks. E.g. it wouldn't be safe to move the insn in the predecessor due to other uses.

This actually ties back to one question that I don't think we answered. Do we legalize on the type (i.e., s8 to s32) or the size and type can be different (i.e., s8(8b) to s8(32b))?
It seems to me we are trying to write <4 x s8> = s8(32b), ...., but maybe we want <4 x s8> = s32, ....

I've had a think about what having separate type and container sizes would actually mean. For brevity, let’s call values which have distinct type and container sizes “partial values”. A partial value s8:s32 means that the upper 24 bits of this 32 bit register is always undef. For some operations, it should always be possible to ignore the type size and just use the container size for selection. E.g. non-flag setting G_ADD could select a 32 bit add and satisfy the semantics of an s8 add. But for other operations like shifts, or count-leading-zeros, we can't use a wider operation type, so the entire chain of partial value operations would be restricted to selecting the narrower type, rather than the container. And at that point, the container type may as well not be there. There may be a way around this issue I haven't seen though.

Anyhow, to be concrete, I am fine with the implicit truncate, we know this is not too bad based on SDISel experience, I want to make sure we consider all our options here.

Sure. Given that we already have this implicit truncating behavior on account of G_MERGE being an omnipotent operation, should we allow the implicit truncation with G_BUILD_VECTOR for now? If we have problems with it later we can revisit the idea of adding a separate opcode/something else.

Cheers,
-Quentin

Fri, Nov 2, 8:19 AM

Tue, Oct 30

aemerson added a comment to D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.

Thanks @aditya_nandakumar for the context.

I understand where you're coming from.

What I meant is that I would rather have one opcode of build_vector and one for build_vector with trunc. The rationale is that it makes it clear what you want to achieve and it makes for a stronger type verifier.

Tue, Oct 30, 4:10 PM
aemerson accepted D53740: [globalisel][irtranslator] Verify that DILocations aren't lost in translation.

LGTM with the nits addressed.

Tue, Oct 30, 9:47 AM

Mon, Oct 29

aemerson updated the diff for D53629: [GlobalISel] Restrict G_MERGE_VALUES capability and replace with new opcodes.

Updated AArch64 legalization. I've removed the unsupported case since we're actually making it valid.

Mon, Oct 29, 9:38 AM
aemerson added inline comments to D53740: [globalisel][irtranslator] Verify that DILocations aren't lost in translation.
Mon, Oct 29, 9:32 AM
aemerson updated the diff for D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.

Updated patch to allow G_BUILD_VECTOR to have scalar operands not identical to the result vector element types. This allows implicit truncation.

Mon, Oct 29, 9:29 AM
aemerson added inline comments to D53740: [globalisel][irtranslator] Verify that DILocations aren't lost in translation.
Mon, Oct 29, 6:32 AM

Fri, Oct 26

aemerson added inline comments to D53629: [GlobalISel] Restrict G_MERGE_VALUES capability and replace with new opcodes.
Fri, Oct 26, 7:13 AM

Thu, Oct 25

aemerson closed D53592: [GlobalISel] Use the target preferred type for G_EXTRACT_VECTOR_ELT index.

Committed in r345265.

Thu, Oct 25, 7:09 AM
aemerson committed rL345265: [GlobalISel] Use the target preferred type for G_EXTRACT_VECTOR_ELT index..
[GlobalISel] Use the target preferred type for G_EXTRACT_VECTOR_ELT index.
Thu, Oct 25, 7:07 AM

Wed, Oct 24

aemerson updated subscribers of D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.

+ @huntergr On a tangential note, G_BUILD_VECTOR for expressing broadcasts of scalars won't work for SVE and other variable vector width targets. We do however still leave the door open here for a new G_BROADCAST opcode in future.

Wed, Oct 24, 8:01 AM
aemerson added a comment to D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.

Are two different opcodes for this really needed? Why not a single opcode with uniformly typed operands, either scalar or vector, which concatenates the operands as an appropriately sized vector? I know there's precedent for the separation elsewhere in LLVM, but it has always seemed redundant to me personally. The code for handling the BUILD vs. CONCAT cases tends to be very similar.

Wed, Oct 24, 7:52 AM

Tue, Oct 23

aemerson added a dependency for D53629: [GlobalISel] Restrict G_MERGE_VALUES capability and replace with new opcodes: D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.
Tue, Oct 23, 6:10 PM
aemerson added a dependent revision for D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes: D53629: [GlobalISel] Restrict G_MERGE_VALUES capability and replace with new opcodes.
Tue, Oct 23, 6:10 PM
aemerson created D53629: [GlobalISel] Restrict G_MERGE_VALUES capability and replace with new opcodes.
Tue, Oct 23, 6:10 PM
aemerson added a dependency for D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes: D53592: [GlobalISel] Use the target preferred type for G_EXTRACT_VECTOR_ELT index.
Tue, Oct 23, 11:29 AM
aemerson added a dependent revision for D53592: [GlobalISel] Use the target preferred type for G_EXTRACT_VECTOR_ELT index: D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.
Tue, Oct 23, 11:29 AM
aemerson created D53594: [GlobalISel] Introduce G_BUILD_VECTOR and G_CONCAT_VECTOR opcodes.
Tue, Oct 23, 11:27 AM
aemerson created D53592: [GlobalISel] Use the target preferred type for G_EXTRACT_VECTOR_ELT index.
Tue, Oct 23, 11:18 AM

Oct 15 2018

aemerson added a comment to D52803: [GISel]: Add support for CSEing continuously during GISel passes.

Thanks for working on this. Apart from Daniel's suggestion, I have a few more comments but haven't done an in depth analysis of the memory costs/algorithmic properties.

Oct 15 2018, 11:20 AM

Oct 11 2018

aemerson committed rL344251: [InstCombine] Fix SimplifyLibCalls erasing an instruction while IC still had….
[InstCombine] Fix SimplifyLibCalls erasing an instruction while IC still had…
Oct 11 2018, 7:53 AM
aemerson closed D52729: [InstCombine] Fix SimplifyLibCalls erasing an instruction while IC still had references to it.
Oct 11 2018, 7:53 AM
aemerson updated the diff for D52729: [InstCombine] Fix SimplifyLibCalls erasing an instruction while IC still had references to it.
Oct 11 2018, 7:45 AM
aemerson added inline comments to D52729: [InstCombine] Fix SimplifyLibCalls erasing an instruction while IC still had references to it.
Oct 11 2018, 7:34 AM

Oct 9 2018

aemerson added a comment to D52729: [InstCombine] Fix SimplifyLibCalls erasing an instruction while IC still had references to it.

Ping.

Oct 9 2018, 4:52 AM

Oct 1 2018

aemerson created D52729: [InstCombine] Fix SimplifyLibCalls erasing an instruction while IC still had references to it.
Oct 1 2018, 9:17 AM

Sep 20 2018

aemerson requested review of D51953: [GlobalISel] Add a new IR canonicalization pass.
Sep 20 2018, 5:58 AM
aemerson updated the diff for D51953: [GlobalISel] Add a new IR canonicalization pass.

@aditya_nandakumar I've added a target hook that defaults to enabling this.

Sep 20 2018, 5:58 AM
aemerson accepted D48575: [GISel]; Add a helper legalization rule for legalizing addressspacecast if no-op.

This seems like something that most targets would want done by default. I wonder if we should have a standard set of legalizer actions that targets can use. LGTM anyway.

Sep 20 2018, 5:52 AM

Sep 17 2018

aemerson added a comment to D51953: [GlobalISel] Add a new IR canonicalization pass.

Hi Amara - would it be possible to add this as part of AArch64 pass pipeline? Adding this to all targets would result in needless burning of compile time for targets that don't need this.

Sep 17 2018, 3:53 PM
aemerson added a comment to D51953: [GlobalISel] Add a new IR canonicalization pass.

This isn't really ideal because of how trivial it is currently. The issue is that if we added the capability to InstSimplify (which is where it would fit most naturally), we'd still end up with the problem of running the whole of InstSimplify in the GlobalISel pipeline. It's reasonable for now I think so I'll commit with the changes requested.

Sep 17 2018, 9:24 AM
aemerson added a comment to D52131: [GISel][NFC]: Make MachineIRBuilder fully stateless.

Looks ok, if a bit cumbersome with the additional state (do we need to hold references to it?). I'd like to see how this state is used with the CSE builder first though.

Sep 17 2018, 9:18 AM
aemerson committed rL342397: Revert "Revert r342183 "[DAGCombine] Fix crash when store merging created an….
Revert "Revert r342183 "[DAGCombine] Fix crash when store merging created an…
Sep 17 2018, 7:43 AM

Sep 13 2018

aemerson committed rL342183: [DAGCombine] Fix crash when store merging created an extract_subvector with….
[DAGCombine] Fix crash when store merging created an extract_subvector with…
Sep 13 2018, 2:30 PM
aemerson closed D51831: [DAGCombine] Fix crash when store merging created an extract_subvector with invalid index.
Sep 13 2018, 2:30 PM
aemerson added a comment to D51831: [DAGCombine] Fix crash when store merging created an extract_subvector with invalid index.

Ok, I'm surprised that would be a realistic scenario but I'll make the change. Thanks.

Sep 13 2018, 11:02 AM

Sep 12 2018

aemerson updated the diff for D51831: [DAGCombine] Fix crash when store merging created an extract_subvector with invalid index.

You're right, that's a simplified expression.

Sep 12 2018, 3:38 PM
aemerson added a comment to D51831: [DAGCombine] Fix crash when store merging created an extract_subvector with invalid index.

Ping.

Sep 12 2018, 7:13 AM
aemerson added a comment to D51953: [GlobalISel] Add a new IR canonicalization pass.

Hi Quentin,

Sep 12 2018, 4:14 AM

Sep 11 2018

aemerson created D51953: [GlobalISel] Add a new IR canonicalization pass.
Sep 11 2018, 3:02 PM

Sep 8 2018

aemerson created D51831: [DAGCombine] Fix crash when store merging created an extract_subvector with invalid index.
Sep 8 2018, 6:32 AM

Sep 5 2018

aemerson added a comment to D51145: Guard FMF context by excluding some FP operators from FPMathOperator.

I added one more non fmf instruction and there is room to add others if needed.

There's also discussion about the definition of FPMathOperator and the relation to FMF here:
https://bugs.llvm.org/show_bug.cgi?id=38086
D51646

Sep 5 2018, 5:11 PM
aemerson added inline comments to D51646: DAG: Preserve FMF when creating fminnum/fmaxnum.
Sep 5 2018, 5:08 PM

Sep 4 2018

aemerson added a comment to D51145: Guard FMF context by excluding some FP operators from FPMathOperator.

Ok, to me it seems like instructions for which fast math flags can't apply shouldn't be classed as FPMathOperators. insertelement/extractelement are just moving raw bits. If we disallowed those instruction types in the FPMathOperator classof() then this problem should go away, and we don't incorrectly relax FP semantics like in the case I pointed out.

Sep 4 2018, 6:22 AM

Aug 31 2018

aemerson added a comment to D51145: Guard FMF context by excluding some FP operators from FPMathOperator.

I’m not seeing how FP instructions can not carry flags. The IR semantics are defined to be strict FP unless explicitly relaxed.

Aug 31 2018, 12:35 PM
aemerson updated subscribers of D51145: Guard FMF context by excluding some FP operators from FPMathOperator.
Aug 31 2018, 12:17 PM
aemerson added a comment to D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last.

It can't do that all the time, with these G_ICMPs for example it also has to swap the predicate (not that we even have imported patterns that could possibly match for AArch64).

Why not?
I understand G_ICMPs are special, but we could come up with whatever complicated logic in TableGen.

Aug 31 2018, 12:00 PM
aemerson added a comment to D51145: Guard FMF context by excluding some FP operators from FPMathOperator.

Hit submit too early:
So with the above code B will not have the flag cleared? If that's the case it doesn't seem right to me.

Aug 31 2018, 11:45 AM
aemerson added a comment to D51145: Guard FMF context by excluding some FP operators from FPMathOperator.

So with this change, if you have:

Aug 31 2018, 11:39 AM

Aug 30 2018

aemerson added a comment to D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last.

So overall I think we should have some form of IR canonicalization before translation for the majority of cases to be handled for -O0.

Aug 30 2018, 10:21 AM
aemerson added a comment to D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last.

Going back to a higher-level description for all that stuff, I wonder if ISel could already handle this.

Indeed, it seems easy, at least conceptually, to teach tablegen to check for the commuted patterns to get the immediate version whenever possible before trying the non-immediate variant.

It can't do that all the time, with these G_ICMPs for example it also has to swap the predicate (not that we even have imported patterns that could possibly match for AArch64).

Aug 30 2018, 10:16 AM

Aug 29 2018

aemerson added a comment to D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last.

I'm not against a separate IR canonicalization stage, even though it's a bit overkill for this particular case. At the moment it looks like InstCombine is doing the canonicalizaton for this case, so re-running that is out of the question. A new pass looks to be on the cards. Anyone else have opinions on this?

Does that mean that something after the last InstCombine produces icmp's with the non-canonical operand order? If so maybe that something needs to be chased down and fixed instead.

Aug 29 2018, 3:49 PM
aemerson added reviewers for D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last: bogner, aditya_nandakumar, volkan.

I'm not against a separate IR canonicalization stage, even though it's a bit overkill for this particular case. At the moment it looks like InstCombine is doing the canonicalizaton for this case, so re-running that is out of the question. A new pass looks to be on the cards. Anyone else have opinions on this?

Aug 29 2018, 3:08 PM
aemerson added a comment to D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last.

Hi Amara,

That patch worries me, because I feel that we are going to pull all the LLVM IR code that does canonicalization.
The way I see it, is the input IR should already be in a canonical form and thus we don't have to do that.

If that's not the case, I would argue that bad output code is fine (garbage in, garbage out).

What do you think?

Cheers,
-Quentin

Aug 29 2018, 2:29 AM

Aug 28 2018

aemerson added inline comments to D44704: [GlobalISel][X86][ARM] Relaxing type constraints on G_SHL and friends.
Aug 28 2018, 4:58 PM
aemerson accepted D44704: [GlobalISel][X86][ARM] Relaxing type constraints on G_SHL and friends.

I'd like to get this in. LGTM but needs one issue addressed.

Aug 28 2018, 4:56 PM
aemerson accepted D51197: [GISel]: Add missing opcodes for overflow intrinsics.

x86 is still using UADDE, and it's generated only by IRTranslator, so if you do this then x86 will lose support for compiling llvm.uadd.with.overflow intrinsics. @igorb what do you think?

Which is exposing a hole in our general GISel testing, where individual changes in passes can result in overall support for some input IR to be lost.

Hi,
I think currently X86 use G_UADDE generated by Legalizer to support 64bit add on 32bit architecture.

Regards,
Igor

Aug 28 2018, 9:01 AM
aemerson created D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last.
Aug 28 2018, 8:34 AM
aemerson added a comment to D51197: [GISel]: Add missing opcodes for overflow intrinsics.

x86 is still using UADDE, and it's generated only by IRTranslator, so if you do this then x86 will lose support for compiling llvm.uadd.with.overflow intrinsics. @igorb what do you think?

Aug 28 2018, 2:55 AM

Aug 21 2018

aemerson accepted D51005: [aarch64][mc] Don't lookup symbols when there is no symbol lookup callback.

Looks like Lang added the original code, but LGTM anyway. I even think we did this exact change downstream a few years ago at ARM...

Aug 21 2018, 8:05 AM

Aug 15 2018

aemerson committed rL339796: [InstCombine] Fix IC trying to create a xor of pointer types..
[InstCombine] Fix IC trying to create a xor of pointer types.
Aug 15 2018, 10:47 AM
aemerson closed D50775: [InstCombine] Fix IC trying to create a xor of pointer types.
Aug 15 2018, 10:47 AM
aemerson updated the diff for D50775: [InstCombine] Fix IC trying to create a xor of pointer types.

Sure, done.

Aug 15 2018, 10:36 AM
aemerson created D50775: [InstCombine] Fix IC trying to create a xor of pointer types.
Aug 15 2018, 6:39 AM

Aug 14 2018

aemerson committed rL339674: [GlobalISel][IRTranslator] Fix a bug in handling repeating struct types during….
[GlobalISel][IRTranslator] Fix a bug in handling repeating struct types during…
Aug 14 2018, 5:05 AM
This revision was not accepted when it landed; it landed in state Needs Revision.
Aug 14 2018, 5:05 AM
aemerson added inline comments to D50401: [GISel]: Add Opcodes for a few Libm Intrinsics.
Aug 14 2018, 4:59 AM
aemerson commandeered D49442: [GlobalISel] Fix offsets to valueIsSplit.

I'll take over and fix this in the way I suggested. Thanks for reporting this!

Aug 14 2018, 4:56 AM

Aug 10 2018

aemerson added a comment to D50401: [GISel]: Add Opcodes for a few Libm Intrinsics.

I'm a little uneasy about specifying libm in the names of the intrinsics. The langref mentions libm in the description, but the semantics don't exactly match due to ignoring errno. That said, I don't really have a suggestion for a better name, so the only thing I can ask is that we make it a bit more explicit in the documentation what we mean by "LIBM" here.

Aug 10 2018, 8:54 AM

Aug 8 2018

aemerson removed a reviewer for D49442: [GlobalISel] Fix offsets to valueIsSplit: llvm-commits.
Aug 8 2018, 8:23 AM

Aug 7 2018

aemerson added a comment to D49442: [GlobalISel] Fix offsets to valueIsSplit.

Thinking about this more, I can't think of any reason why we'd ever want to add offsets to an existing offset list. It would probably be better if valueIsSpit cleared the vector (and the doc comment made this clear).

Aug 7 2018, 12:36 PM
aemerson requested changes to D49442: [GlobalISel] Fix offsets to valueIsSplit.
Aug 7 2018, 12:31 PM
aemerson accepted D49442: [GlobalISel] Fix offsets to valueIsSplit.

Could you upload with more context please, and a test case?

Aug 7 2018, 12:30 PM

Jul 31 2018

aemerson committed rL338476: [GlobalISel][IRTranslator] Use RPO traversal when visiting blocks to translate..
[GlobalISel][IRTranslator] Use RPO traversal when visiting blocks to translate.
Jul 31 2018, 7:18 PM

Jul 30 2018

aemerson committed rL338337: [AArch64][GlobalISel] Add isel support for G_BLOCK_ADDR..
[AArch64][GlobalISel] Add isel support for G_BLOCK_ADDR.
Jul 30 2018, 5:09 PM
aemerson committed rL338336: [AArch64][GlobalISel] Make G_BLOCK_ADDR legal..
[AArch64][GlobalISel] Make G_BLOCK_ADDR legal.
Jul 30 2018, 5:09 PM
This revision was not accepted when it landed; it landed in state Needs Review.
Jul 30 2018, 5:09 PM
aemerson closed D49902: [AArch64][GlobalISel] Make G_BLOCK_ADDR legal.
Jul 30 2018, 5:09 PM
aemerson committed rL338335: [GlobalISel] Add a G_BLOCK_ADDR opcode to handle IR blockaddress constants..
[GlobalISel] Add a G_BLOCK_ADDR opcode to handle IR blockaddress constants.
Jul 30 2018, 5:09 PM
aemerson closed D49900: [GlobalISel] Add a G_BLOCK_ADDR opcode to handle IR blockaddress constants..
Jul 30 2018, 5:09 PM
aemerson added inline comments to D49900: [GlobalISel] Add a G_BLOCK_ADDR opcode to handle IR blockaddress constants..
Jul 30 2018, 11:14 AM
aemerson added inline comments to D48600: [GISel]:Add Opcodes for CTLZ/CTTZ/CTPOP.
Jul 30 2018, 5:46 AM

Jul 29 2018

aemerson added a comment to D49660: [GlobalISel] Rewrite CallLowering::lowerReturn to accept multiple VRegs per Value.

Thanks for taking this on. I think some x86 tests would also be good here as there evidently isn't much coverage at the moment.

Jul 29 2018, 11:51 AM

Jul 26 2018

aemerson added a dependency for D49902: [AArch64][GlobalISel] Make G_BLOCK_ADDR legal: D49900: [GlobalISel] Add a G_BLOCK_ADDR opcode to handle IR blockaddress constants..
Jul 26 2018, 7:23 PM
aemerson added a dependent revision for D49900: [GlobalISel] Add a G_BLOCK_ADDR opcode to handle IR blockaddress constants.: D49902: [AArch64][GlobalISel] Make G_BLOCK_ADDR legal.
Jul 26 2018, 7:23 PM
aemerson added a dependent revision for D49902: [AArch64][GlobalISel] Make G_BLOCK_ADDR legal: D49903: [AArch64][GlobalISel] Add isel support for G_BLOCK_ADDR.
Jul 26 2018, 7:23 PM
aemerson added a dependency for D49903: [AArch64][GlobalISel] Add isel support for G_BLOCK_ADDR: D49902: [AArch64][GlobalISel] Make G_BLOCK_ADDR legal.
Jul 26 2018, 7:23 PM
aemerson created D49903: [AArch64][GlobalISel] Add isel support for G_BLOCK_ADDR.
Jul 26 2018, 7:22 PM
aemerson created D49902: [AArch64][GlobalISel] Make G_BLOCK_ADDR legal.
Jul 26 2018, 7:20 PM
aemerson created D49900: [GlobalISel] Add a G_BLOCK_ADDR opcode to handle IR blockaddress constants..
Jul 26 2018, 7:17 PM

Jul 25 2018

aemerson committed rL337994: [GlobalISel] Fall back to SDISel for swifterror/swiftself attributes..
[GlobalISel] Fall back to SDISel for swifterror/swiftself attributes.
Jul 25 2018, 6:26 PM

Jul 3 2018

aemerson committed rL336209: [AArch64][GlobalISel] Fix fallbacks introduced in r336120 due to unselectable….
[AArch64][GlobalISel] Fix fallbacks introduced in r336120 due to unselectable…
Jul 3 2018, 9:04 AM

Jul 2 2018

aemerson committed rL336120: [AArch64][GlobalISel] Any-extend vararg parameters to stack slot size on Darwin..
[AArch64][GlobalISel] Any-extend vararg parameters to stack slot size on Darwin.
Jul 2 2018, 9:44 AM

Jun 24 2018

aemerson requested changes to D45543: [globalisel] Add a combiner helpers for extending loads and use them in a pre-legalize combiner for AArch64.
Jun 24 2018, 7:17 PM

Jun 20 2018

aemerson added a comment to D45543: [globalisel] Add a combiner helpers for extending loads and use them in a pre-legalize combiner for AArch64.

Hi Daniel, sorry for the delay.

Jun 20 2018, 10:39 PM

Jun 4 2018

aemerson committed rL333970: [MIRParser] Add parser support for 'true' and 'false' i1s..
[MIRParser] Add parser support for 'true' and 'false' i1s.
Jun 4 2018, 5:21 PM