Page MenuHomePhabricator

aemerson (Amara Emerson)
Asian George Costanza

Projects

User does not belong to any projects.

User Details

User Since
Sep 9 2013, 3:45 AM (428 w, 5 d)

The sea was angry that day, my friends - like an old man trying to send back soup in a deli.

Recent Activity

Mon, Nov 22

aemerson added a comment to D112852: [GlobalISel] Allow DBG_VALUE to use undefined vregs before LiveDebugValues.

Requesting changes for the missing MIR serialization of the new property.

The issue here is determining where the barrier for disallowing these undefined vregs should be. LiveDebugVariables naturally discards these particular uses, so this is sufficient based on my knowledge.

Well to me this feels like we are making the intermediate representation more complicated (I consider it more complicated because DBG_VALUE instructions are special with lifetime rules now) for a very small gain.

That said I don't feel strongly about this. If others think this is benefitial then we can go ahead.

We haven’t changed the meaning of the MIR, we just clarified the existing semantics on the RFC thread. There’s no middle ground here as far as I can see, either it’s valid to have undefined uses or not. If it is, then we’re free to do anything that leaves them around.

Mon, Nov 22, 5:28 PM · Restricted Project

Tue, Nov 16

aemerson committed rGdcd8728d8394: Remove unnecessary <any> include. (authored by aemerson).
Remove unnecessary <any> include.
Tue, Nov 16, 12:59 AM
aemerson added inline comments to D109131: [GlobalISel] Add a store-merging optimization pass and enable for AArch64..
Tue, Nov 16, 12:37 AM · Restricted Project

Mon, Nov 15

aemerson committed rGdc84770d559b: [GlobalISel] Add a store-merging optimization pass and enable for AArch64. (authored by aemerson).
[GlobalISel] Add a store-merging optimization pass and enable for AArch64.
Mon, Nov 15, 9:11 PM
aemerson closed D109131: [GlobalISel] Add a store-merging optimization pass and enable for AArch64..
Mon, Nov 15, 9:10 PM · Restricted Project

Thu, Nov 11

aemerson added a comment to D113030: Add a new tool for parallel safe bisection, "llvm-bisectd"..

I would like to note that there's some rudimentary support
for previous generation of this scattered throught the codebase,
namely DebugCounters for bugpoint.

I don't really have an opinion on the proposal at large,
but i think it may be important to not just introduce a yet another variant
of dealing with the same issue, but only have a single good modern way.

Yes, I've seen DebugCounter. It's useful when you're already identified the file where something is going wrong, and you can enable the counters and pass counter values to opt. It doesn't however work across multiple TUs or support parallel debugging, so it's not solving the same problem.

Perhaps it'd be worth considering the overlap here, and maybe avoiding it: What would it be like if this new thing /only/ bisected at the granularity of a whole compilation action (ie: one invocation of clang), rather than specific optimizations? (possibly even only at the "whole compiler" granularity - using two compilers - and choosing between one or the other for each compilation)

Then once the specific file has been identified, use the existing sub-file granularity tools (a wrapper script could help cover both of these for the user so it wasn't a bunch more manual work).

I think that might help prevent overlap of functionality/re-implementing similar/the same functionality through different mechanisms for reducing specific optimization applications?

I think that restricting it to only allow bisection across translation units would be artificially constraining the functionality to not step on the toes of other features. That in itself doesn't seem the right approach, because the simplest thing right now is to support arbitrary bisection granularities. If we constrained it to only allow bisection down to TUs, then we haven't really simplified or re-used any code, all we've done is to make the user experience worse.

Thu, Nov 11, 3:55 PM · Restricted Project

Tue, Nov 9

aemerson committed rGaf4dc633f86f: [AArch64][GlobalISel] Fix atomic truncating stores from generating invalid… (authored by aemerson).
[AArch64][GlobalISel] Fix atomic truncating stores from generating invalid…
Tue, Nov 9, 8:48 PM

Wed, Nov 3

aemerson accepted D93154: GlobalISel: remove assert that memcpy Src and Dst addrspace must be identical.

LGTM.

Wed, Nov 3, 3:15 PM · Restricted Project

Tue, Nov 2

aemerson added a comment to D113030: Add a new tool for parallel safe bisection, "llvm-bisectd"..

I would like to note that there's some rudimentary support
for previous generation of this scattered throught the codebase,
namely DebugCounters for bugpoint.

I don't really have an opinion on the proposal at large,
but i think it may be important to not just introduce a yet another variant
of dealing with the same issue, but only have a single good modern way.

Tue, Nov 2, 1:09 PM · Restricted Project
aemerson added a comment to D113030: Add a new tool for parallel safe bisection, "llvm-bisectd"..

Let me just step back a little bit and say that now that I think about what we did, having something that answers "should I run in this instance" is desirable, the implementation doesn't really matter. We did it with function attributes, but having a bisect client API like you're introducing is fine.
My only complain is that the client interface should not have remote in the name :P.

From an abstraction level, we need two things:

  1. Something that tells if an optimization needs to run (the remote bisect client here)
  2. Something that drives the on/off of the optimizations based on the previous state (here your daemon)

The way we did that was:
For #1 we added annotations in the IR
For #2 we implemented the driver directly in our JIT daemon

Essentially, that boils down to something that formulates a plan and something that executes the plan. At one point I was thinking that formulating the plan could be changing the pass pipeline (don't insert what you don't want to run), but that look like too much work :).

How does that work when you have parallel builds?

Each module is assigned an ID and the bisect plan and previous state are mapped to this ID.
The ID is saved in the module metadata but for now we didn't use it since all we needed was added to the IR via annotations (i.e., we didn't need to come up with a key to ask information about specific pass). In that regard, you're approach is more general.
For the ID, we used a hash of the module before the bisect annotations were added, i.e., as long as you don't change the front-end the ID are stable between runs.

To summarize:
Compute the module ID -> add annotation based on past information -> run the backend (at this point, the backend runs by itself.)

When multiple clang processes are running simultaneously, and you want to bisect to a specific translation unit, and then within that TU to a specific point in the module, don't you need some co-ordination?

At a high level here is what the driver was doing:

  • Bisect optnone on each module
  • Find the module(s) that creates the problem (the minimal set of modules that needs optimizations turn on)
  • Do the same on each function (the minimal set may involve more than one function)
  • Try to "outline" the basic blocks of each problematic function and do the same process on the newly created functions
  • Split the problematic basic block to make them smaller and continue
  • When you're happy with the size of the basic blocks, start bisecting the optimizations on the problematic functions (possibly basic block extracted). Right now we were only bisecting a handful of optimization because the final diff with the basic block splitting usually made the faulty optimization easy to find by hand.

The way it worked is all that state was saved in a file <shaderID>-bisect-info. You could bootstrap the process by populating the file by hand, i.e., by telling the JIT process which module you want to bisect.

As far as bisecting to a specific point in the TU, we were always going all the way down to the executable then you had to supply a script that tells whether or not the program is working. That's similar to what git bisect is doing (if the script runs 0, the program works, if that's one it doesn't). In your script you could check for whatever (specific sequence of asm, executable producing some results, etc.)

Note: The pass I was talking about in my previous reply that we insert in the LLVM pipeline, is generating all the information to start the bisect process (e.g., the shader ID, the list of all the functions, the list of all basic blocks). Then the driver was using this information to tell that pass to add some annotation on some function (e.g., optnone, noinline, etc.), but also to split some basic block and outline them (and attach some annotation on them).

Cheers,
-Quentin

Tue, Nov 2, 12:20 PM · Restricted Project
aemerson added a comment to D113030: Add a new tool for parallel safe bisection, "llvm-bisectd"..

Hi Amara,

I am kind of repeating what I said in https://reviews.llvm.org/D113031, but putting it here for better visibility.

I think the thing that drives the bisection shouldn't trickle down in the optimizations themselves, instead I would rather this information to be encoded in the IR itself (like a generalization of optnone).

For instance, for us a daemon based approach doesn't work at all because we are running a JIT compiler that runs in its own sandbox and we cannot query an external process from it.

Internally, we developed a bisect tool that annotates the IR upfront (to make an analogy with clang, this is as if clang would add a bunch of "bisect" attribute on the IR) before sending it for compilation instead of having the backend query a bisection client.
Note: technically we didn't modify clang, we instead had a specific pass at the beginning of the LLVM pipeline that would make all the bisection decisions, but also perform some transformation to isolate the bugs (like creating functions out of basic blocks, splitting the blocks to make the functions smaller, and blocking inlining.)

Cheers,
-Quentin

Tue, Nov 2, 11:12 AM · Restricted Project
aemerson added a comment to D113030: Add a new tool for parallel safe bisection, "llvm-bisectd"..

D113031 contains an example of a client for this in GlobalISel.

Tue, Nov 2, 10:23 AM · Restricted Project
aemerson requested review of D113031: [GlobalISel] Add a bisection point after instruction selection..
Tue, Nov 2, 10:18 AM · Restricted Project
aemerson requested review of D113030: Add a new tool for parallel safe bisection, "llvm-bisectd"..
Tue, Nov 2, 10:17 AM · Restricted Project

Sun, Oct 31

aemerson added reviewers for D112852: [GlobalISel] Allow DBG_VALUE to use undefined vregs before LiveDebugValues: dsanders, aditya_nandakumar, tstellar, nhaehnle, dblaikie.
Sun, Oct 31, 6:38 PM · Restricted Project

Fri, Oct 29

aemerson committed rG5dd9e019ddb4: [AArch64][GlobalISel] Fix an crash in RBS due to a new regclass being added. (authored by aemerson).
[AArch64][GlobalISel] Fix an crash in RBS due to a new regclass being added.
Fri, Oct 29, 11:47 AM

Oct 19 2021

aemerson added a comment to D111132: [GlobalISel] Better verification of G_UNMERGE_VALUES.
  1. Splitting a vector into its elements (the converse of G_BUILD_VECTOR).

Is there any appetite for using a new G_SPLIT_VECTOR opcode for this case?

I don't see a reason to have a scalar and vector version of the same thing.

You mean, splitting a vector into vectors vs splitting a vector into scalars? Then why do we have both G_BUILD_VECTOR and G_CONCAT_VECTORS? The asymmetry annoys me!

Oct 19 2021, 11:15 AM · Restricted Project

Oct 18 2021

aemerson added a comment to D111777: [GlobalISel] Refactor CSEMIRBuilder's handling of unary op constant folding. NFC..

No particular objection from me, though it would be more consistent if ConstantFoldUnaryOp built the G_CONSTANT, just like ConstantFoldVectorUnaryOp builds the G_BUILD_VECTOR.

That then raises the question of how you would call these functions from CombinerHelper match* functions, which don't want to build the IR until you get to the corresponding apply* function.

That then also raises the question of whether we really want to be doing constant folding both in the builder and in combiners.

I think the answer is yes, but for different reasons. I think constant folding in the builder only makes sense for handful of artifact-like operations, but general constant folding is always going to be needed in the combiners as other operations fold to constants

Oct 18 2021, 2:29 PM · Restricted Project
aemerson added a comment to D111970: [GlobalISel][Legalizer] Restore eraseFromParentAndMarkDBGValuesForRemoval() for CallLowering artifacts..

Please see the discussion here: https://groups.google.com/g/llvm-dev/c/R9lSoAqh5e4

Oct 18 2021, 2:28 PM · Restricted Project

Oct 15 2021

aemerson added inline comments to D111888: [AArch64][GISel] Optimize 8 and 16 bit variants of uaddo..
Oct 15 2021, 10:38 AM · Restricted Project

Oct 13 2021

aemerson added inline comments to D111777: [GlobalISel] Refactor CSEMIRBuilder's handling of unary op constant folding. NFC..
Oct 13 2021, 11:19 PM · Restricted Project
aemerson requested review of D111777: [GlobalISel] Refactor CSEMIRBuilder's handling of unary op constant folding. NFC..
Oct 13 2021, 11:17 PM · Restricted Project

Oct 12 2021

aemerson committed rG5abce56edbee: [GlobalISel] Add support for constant vector folding of binops in CSEMIRBuilder. (authored by aemerson).
[GlobalISel] Add support for constant vector folding of binops in CSEMIRBuilder.
Oct 12 2021, 11:31 AM
aemerson closed D111524: [GlobalISel] Add support for constant vector folding of binops in CSEMIRBuilder..
Oct 12 2021, 11:31 AM · Restricted Project
aemerson added inline comments to D111524: [GlobalISel] Add support for constant vector folding of binops in CSEMIRBuilder..
Oct 12 2021, 10:00 AM · Restricted Project

Oct 11 2021

aemerson committed rG53ebfa7c5d1b: [AArch64][GlobalISel] Fix combiner assertion in matchConstantOp(). (authored by aemerson).
[AArch64][GlobalISel] Fix combiner assertion in matchConstantOp().
Oct 11 2021, 3:55 PM
aemerson updated the diff for D111524: [GlobalISel] Add support for constant vector folding of binops in CSEMIRBuilder..

Hoist end iterator eval in loop. Rebase on test check regeneration.

Oct 11 2021, 3:16 PM · Restricted Project
aemerson committed rGda904719e9a7: [GlobalISel] Regenerate some MIR tests with CHECK-NEXT for another patch. (authored by aemerson).
[GlobalISel] Regenerate some MIR tests with CHECK-NEXT for another patch.
Oct 11 2021, 2:40 PM
aemerson added a comment to D111524: [GlobalISel] Add support for constant vector folding of binops in CSEMIRBuilder..

No objections from me, but I do wonder if there's a way to apply this more consistently to all the constant folds, not just the binops.

Oct 11 2021, 9:35 AM · Restricted Project
aemerson requested review of D111524: [GlobalISel] Add support for constant vector folding of binops in CSEMIRBuilder..
Oct 11 2021, 12:14 AM · Restricted Project
aemerson accepted D107160: [AArch64] Do not emit an extra zero-extend for i1 argument.
Oct 11 2021, 12:03 AM · Restricted Project

Oct 10 2021

aemerson committed rGf1e9ecea442a: [AArch64][GlobalISel] Legalize G_VECREDUCE_XOR. Treated same as other bitwise… (authored by aemerson).
[AArch64][GlobalISel] Legalize G_VECREDUCE_XOR. Treated same as other bitwise…
Oct 10 2021, 5:02 PM

Oct 9 2021

aemerson committed rGf95d9c95bbf4: [GlobalISel] Fix the stores of truncates -> wide store combine for non-evenly… (authored by aemerson).
[GlobalISel] Fix the stores of truncates -> wide store combine for non-evenly…
Oct 9 2021, 9:19 PM

Oct 8 2021

aemerson added inline comments to D111036: [GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> (bitwidth - c).
Oct 8 2021, 11:30 AM · Restricted Project
aemerson committed rG17b89f9daad5: [GlobalISel] Improve G_UMHULH -> LSHR combine to accept non-uniform constant… (authored by aemerson).
[GlobalISel] Improve G_UMHULH -> LSHR combine to accept non-uniform constant…
Oct 8 2021, 11:25 AM

Oct 7 2021

aemerson added a comment to D111036: [GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> (bitwidth - c).

Oops sorry about that, I didn't realize this was already on my branch when I committed 72ce310bf0de so this went in by mistake.

Oct 7 2021, 11:55 PM · Restricted Project
aemerson committed rG08b3c0d995d8: [GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> (bitwidth - c) (authored by aemerson).
[GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> (bitwidth - c)
Oct 7 2021, 11:52 PM
aemerson committed rG72ce310bf0de: [GlobalISel][IRTranslator] Fix a use-after-free bug when translating trap-func… (authored by aemerson).
[GlobalISel][IRTranslator] Fix a use-after-free bug when translating trap-func…
Oct 7 2021, 11:52 PM
aemerson closed D111036: [GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> (bitwidth - c).
Oct 7 2021, 11:51 PM · Restricted Project
aemerson added a comment to D111132: [GlobalISel] Better verification of G_UNMERGE_VALUES.
  1. Splitting a vector into subvectors (the converse of G_CONCAT_VECTORS).

Is there any appetite for using a new (G_UNCONCAT_VECTORS???) opcode for this case?

Unfortunately there are a couple of tests that fail the verification I implemented for this case:

Failed Tests (2):

LLVM :: CodeGen/AArch64/GlobalISel/combine-unmerge.mir
LLVM :: CodeGen/AMDGPU/GlobalISel/artifact-combiner-unmerge-values.mir

by building MIR like this: %1:_(<2 x s16>), %2:_(<2 x s16>) = G_UNMERGE_VALUES %0:_(<2 x s32>)

Should this be allowed?

I don't like unmerge being able to do that. Seems better to handle that with a bitcast first.

  1. Splitting a vector into its elements (the converse of G_BUILD_VECTOR).

Is there any appetite for using a new G_SPLIT_VECTOR opcode for this case?

Oct 7 2021, 11:04 PM · Restricted Project
aemerson added a comment to D111223: [GlobalISel] Simplify RegBankSelect.

The low level implementation details look OK to me.

I guess we need to get some agreement about the high level design: is this a good way of handling newly created instructions and BBs? In particular I wonder if there is some way of handling newly created instructions automatically, without having to call setNextInstruction, but I can't quite see how it would work.

Oct 7 2021, 11:01 PM · Restricted Project
aemerson committed rG8bfc0e06dc85: [GlobalISel] Port the udiv -> mul by constant combine. (authored by aemerson).
[GlobalISel] Port the udiv -> mul by constant combine.
Oct 7 2021, 11:37 AM
aemerson closed D110890: [GlobalISel] Port the udiv -> mul by constant combine..
Oct 7 2021, 11:37 AM · Restricted Project
aemerson added inline comments to D110890: [GlobalISel] Port the udiv -> mul by constant combine..
Oct 7 2021, 10:35 AM · Restricted Project

Oct 6 2021

aemerson added a reverting change for rGd95cd81141a4: Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for "unreachable"": rG79d13bf22c16: Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for….
Oct 6 2021, 4:16 AM
aemerson committed rG79d13bf22c16: Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for… (authored by aemerson).
Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for…
Oct 6 2021, 4:16 AM

Oct 5 2021

aemerson accepted D111088: [AArch64][GlobalISel] Fold 64-bit cmps with 64-bit adds.

LGTM. Thanks for at least investigating it.

Oct 5 2021, 11:29 PM · Restricted Project
aemerson committed rG6bc64e24c38a: [GlobalISel] Clear unreachable blocks' contents after selection. (authored by aemerson).
[GlobalISel] Clear unreachable blocks' contents after selection.
Oct 5 2021, 11:06 PM
aemerson closed D111201: [GlobalISel] Clear unreachable blocks' contents after selection..
Oct 5 2021, 11:06 PM · Restricted Project
aemerson requested review of D111201: [GlobalISel] Clear unreachable blocks' contents after selection..
Oct 5 2021, 5:44 PM · Restricted Project
aemerson added a comment to D110603: [GlobalISel][IRTranslator] Emit trap intrinsic for unreachable.

Hi,

I think there is something broken after the relanding of this.
For my out-of-tree target I have a testcase where there exists a block that is unreachable from entry, but that is referenced in a PHI:

body: |
  bb.0:
    liveins: $a0h, $r0
    %0:all(s16) = COPY $a0h
    %1:all(s16) = COPY $r0
    brr_uncond %bb.2

  bb.1:
    brr_uncond %bb.2

  bb.2:
    %2:all(s16) = G_PHI %0(s16), %bb.0, %1(s16), %bb.1
    $a0h = COPY %2

So %bb.1 is dead, but jumps to %bb.2 so the G_PHI in %bb.2 references %bb.1

With this patch we get this result:

body:             |
  ; Instruction count: 5
  bb.0:
    successors: %bb.2(0x80000000)
    liveins: $a0h, $r0
  
    %0:anh_rn = COPY $a0h
    %1:anh_rn = COPY $r0
    brr_uncond %bb.2
  
  bb.2:
    %2:anh_rn = PHI %0, %bb.0, %1, %bb.-1
    $a0h = COPY %2

So %bb.1 is removed, but the PHI now looks broken because %bb.1 has been replace with %bb.-1 instead of the operand being removed completely.

Oct 5 2021, 4:56 PM · Restricted Project
aemerson added a comment to D110890: [GlobalISel] Port the udiv -> mul by constant combine..

Ok to go?

Oct 5 2021, 12:57 PM · Restricted Project
aemerson added a reverting change for rGc93bc508ee44: Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for…: rGde5b16d8ca2d: Revert "Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for….
Oct 5 2021, 8:27 AM
aemerson committed rGde5b16d8ca2d: Revert "Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for… (authored by aemerson).
Revert "Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for…
Oct 5 2021, 8:26 AM
aemerson committed rG3fe475367c46: [AArch64][GlobalISel] Legalize G_VECREDUCE_AND. (authored by aemerson).
[AArch64][GlobalISel] Legalize G_VECREDUCE_AND.
Oct 5 2021, 12:39 AM

Oct 4 2021

aemerson committed rGcfef1803dd83: [GlobalISel] Port over the SelectionDAG stack protector codegen feature. (authored by aemerson).
[GlobalISel] Port over the SelectionDAG stack protector codegen feature.
Oct 4 2021, 9:34 PM
aemerson closed D98200: [GlobalISel] Port over the SelectionDAG stack protector codegen feature..
Oct 4 2021, 9:34 PM · Restricted Project
aemerson added a reverting change for rGd95cd81141a4: Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for "unreachable"": rGc93bc508ee44: Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for….
Oct 4 2021, 6:10 PM
aemerson committed rGc93bc508ee44: Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for… (authored by aemerson).
Revert "Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for…
Oct 4 2021, 6:10 PM
aemerson added a reverting change for rG019041bec324: [GlobalISel][IRTranslator] Emit trap intrinsic for "unreachable": rGd95cd81141a4: Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for "unreachable"".
Oct 4 2021, 3:45 PM
aemerson committed rGd95cd81141a4: Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for "unreachable"" (authored by aemerson).
Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for "unreachable""
Oct 4 2021, 3:45 PM
aemerson added a reverting change for D110603: [GlobalISel][IRTranslator] Emit trap intrinsic for unreachable: rGd95cd81141a4: Revert "[GlobalISel][IRTranslator] Emit trap intrinsic for "unreachable"".
Oct 4 2021, 3:45 PM · Restricted Project
aemerson added a comment to D110603: [GlobalISel][IRTranslator] Emit trap intrinsic for unreachable.

I believe we're also hitting a similar error at https://luci-milo.appspot.com/p/fuchsia/builders/toolchain.ci/clang-mac-x64/b8834277085583722465:

[504/509] Building CXX object libcxx/src/CMakeFiles/cxx_static.dir/filesystem/operations.cpp.o
FAILED: libcxx/src/CMakeFiles/cxx_static.dir/filesystem/operations.cpp.o 
/opt/s/w/ir/x/w/staging/llvm_install/bin/clang++ --target=arm64-apple-darwin --sysroot=/opt/s/w/ir/cache/macos_sdk/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk -DNDEBUG -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilibcxx/include/c++build -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -isysroot /opt/s/w/ir/cache/macos_sdk/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk -mmacosx-version-min=10.15 -fPIC -DLIBCXX_BUILDING_LIBCXXABI -faligned-allocation -nostdinc++ -fvisibility-inlines-hidden -fvisibility=hidden -Wall -Wextra -W -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -I/opt/s/w/ir/x/w/staging/runtimes_build/include/c++/v1 -std=c++20 -MD -MT libcxx/src/CMakeFiles/cxx_static.dir/filesystem/operations.cpp.o -MF libcxx/src/CMakeFiles/cxx_static.dir/filesystem/operations.cpp.o.d -o libcxx/src/CMakeFiles/cxx_static.dir/filesystem/operations.cpp.o -c /opt/s/w/ir/x/w/llvm-project/libcxx/src/filesystem/operations.cpp
unknown operand type
UNREACHABLE executed at llvm/lib/Target/AArch64/AArch64MCInstLower.cpp:262!
clang-14: error: clang frontend command failed with exit code 134 (use -v to see invocation)
Fuchsia clang version 14.0.0 (https://llvm.googlesource.com/a/llvm-project e8477045f6d8229a60f6d10c984ee84a3b05efdf)
Target: arm64-apple-darwin
Thread model: posix
InstalledDir: /opt/s/w/ir/x/w/staging/llvm_install/bin
clang-14: note: diagnostic msg:
Oct 4 2021, 3:44 PM · Restricted Project
aemerson abandoned D87297: [GlobalISel] Add bailout thresholds to CSEMIRBuilder::dominates() and the localizer..

Is this still relevant?

Oct 4 2021, 12:35 PM · Restricted Project
aemerson committed rG8bde5e58c02c: Delay outgoing register assignments to last. (authored by aemerson).
Delay outgoing register assignments to last.
Oct 4 2021, 12:33 PM
aemerson closed D110610: [GlobalISel][CallLowering] Delay outgoing register assignments to last..
Oct 4 2021, 12:33 PM · Restricted Project
aemerson added a comment to D111088: [AArch64][GlobalISel] Fold 64-bit cmps with 64-bit adds.

What happens if we legalize ICMPs by promoting the dest to be at least as wide as the source? I'm finding it hard to follow the recent changes to work around this.

Oct 4 2021, 12:28 PM · Restricted Project
aemerson committed rGdafcbfdaa0cd: [GlobalISel] Widen G_EXTRACT_VECTOR_ELT using anyext instead of sext. (authored by aemerson).
[GlobalISel] Widen G_EXTRACT_VECTOR_ELT using anyext instead of sext.
Oct 4 2021, 12:19 PM
aemerson closed D110469: [GlobalISel] Widen G_EXTRACT_VECTOR_ELT using anyext instead of sext..
Oct 4 2021, 12:19 PM · Restricted Project
aemerson updated the diff for D110890: [GlobalISel] Port the udiv -> mul by constant combine..
Oct 4 2021, 12:06 PM · Restricted Project
aemerson updated the diff for D111036: [GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> (bitwidth - c).

Don't fold if constant RHS is a one value.

Oct 4 2021, 12:05 PM · Restricted Project
aemerson committed rG019041bec324: [GlobalISel][IRTranslator] Emit trap intrinsic for "unreachable" (authored by aemerson).
[GlobalISel][IRTranslator] Emit trap intrinsic for "unreachable"
Oct 4 2021, 11:02 AM
aemerson closed D110603: [GlobalISel][IRTranslator] Emit trap intrinsic for unreachable.
Oct 4 2021, 11:02 AM · Restricted Project
aemerson accepted D110926: [GlobalISel] Support vectors in LegalizerHelper::narrowScalarMul.
Oct 4 2021, 10:30 AM · Restricted Project

Oct 3 2021

aemerson updated the diff for D111036: [GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> (bitwidth - c).

Remove unused header includes.

Oct 3 2021, 11:17 PM · Restricted Project
aemerson requested review of D111036: [GlobalISel] Combine G_UMULH x, (1 << c)) -> x >> (bitwidth - c).
Oct 3 2021, 11:08 PM · Restricted Project
aemerson added a comment to D110469: [GlobalISel] Widen G_EXTRACT_VECTOR_ELT using anyext instead of sext..

ping

Oct 3 2021, 11:07 PM · Restricted Project
aemerson added a comment to D110603: [GlobalISel][IRTranslator] Emit trap intrinsic for unreachable.

ping

Oct 3 2021, 11:06 PM · Restricted Project
aemerson added a comment to D110610: [GlobalISel][CallLowering] Delay outgoing register assignments to last..

ping

Oct 3 2021, 11:06 PM · Restricted Project

Oct 1 2021

aemerson committed rGf41a9cf859a1: [AArch64][GlobalISel] Lower G_SMULH/G_UMULH unless its one of the supported… (authored by aemerson).
[AArch64][GlobalISel] Lower G_SMULH/G_UMULH unless its one of the supported…
Oct 1 2021, 10:15 PM
aemerson updated the diff for D110890: [GlobalISel] Port the udiv -> mul by constant combine..

Address most comments.

Oct 1 2021, 9:05 PM · Restricted Project
aemerson added inline comments to D110890: [GlobalISel] Port the udiv -> mul by constant combine..
Oct 1 2021, 3:19 PM · Restricted Project

Sep 30 2021

aemerson added a comment to D110890: [GlobalISel] Port the udiv -> mul by constant combine..

@arsenm @foad The udiv.i64.ll test has had an abort line put it because this patch causes a G_MULH of <2 x s64> to be generated which is currently not legalized for AMDGPU.

Sep 30 2021, 4:04 PM · Restricted Project
aemerson requested review of D110890: [GlobalISel] Port the udiv -> mul by constant combine..
Sep 30 2021, 4:02 PM · Restricted Project
aemerson committed rGca8316b7048d: [GlobalISel] Extend CombinerHelper::matchConstantOp() to match constant splat… (authored by aemerson).
[GlobalISel] Extend CombinerHelper::matchConstantOp() to match constant splat…
Sep 30 2021, 2:31 PM
aemerson closed D110802: [GlobalISel] Extend CombinerHelper::matchConstantOp() to match constant splat vectors.
Sep 30 2021, 2:31 PM · Restricted Project
aemerson committed rG80f4bb5c6193: [GlobalISel] Extend G_SELECT of known condition combine to vectors. (authored by aemerson).
[GlobalISel] Extend G_SELECT of known condition combine to vectors.
Sep 30 2021, 12:17 PM
aemerson closed D110786: [GlobalISel] Extend G_SELECT of known condition combine to vectors..
Sep 30 2021, 12:17 PM · Restricted Project
aemerson updated the diff for D110786: [GlobalISel] Extend G_SELECT of known condition combine to vectors..

I've changed it to use the vector element size for the APInt.

Sep 30 2021, 4:34 AM · Restricted Project
aemerson updated the diff for D110802: [GlobalISel] Extend CombinerHelper::matchConstantOp() to match constant splat vectors.

Rebase after test re-gen.

Sep 30 2021, 4:18 AM · Restricted Project
aemerson committed rG2e7deee376aa: [AArch64][GlobalISel] Re-generate some tests for D110802. (authored by aemerson).
[AArch64][GlobalISel] Re-generate some tests for D110802.
Sep 30 2021, 4:16 AM
aemerson updated the diff for D110786: [GlobalISel] Extend G_SELECT of known condition combine to vectors..
Sep 30 2021, 4:03 AM · Restricted Project
aemerson requested review of D110802: [GlobalISel] Extend CombinerHelper::matchConstantOp() to match constant splat vectors.
Sep 30 2021, 12:31 AM · Restricted Project

Sep 29 2021

aemerson updated the diff for D110786: [GlobalISel] Extend G_SELECT of known condition combine to vectors..

Rename to isConstantOrConstantSplatVector().

Sep 29 2021, 5:00 PM · Restricted Project
aemerson added inline comments to D110786: [GlobalISel] Extend G_SELECT of known condition combine to vectors..
Sep 29 2021, 4:57 PM · Restricted Project
aemerson requested review of D110786: [GlobalISel] Extend G_SELECT of known condition combine to vectors..
Sep 29 2021, 4:32 PM · Restricted Project
aemerson committed rG1c0e8a98e491: [AArch64][GlobalISel] Widen G_BUILD_VECTOR source & dest element types to s8. (authored by aemerson).
[AArch64][GlobalISel] Widen G_BUILD_VECTOR source & dest element types to s8.
Sep 29 2021, 3:11 PM
aemerson committed rGb2b122ddfaa7: [AArch64][GlobalISel] Add selection tests for vector G_UMULH/G_SMULH. (authored by aemerson).
[AArch64][GlobalISel] Add selection tests for vector G_UMULH/G_SMULH.
Sep 29 2021, 2:58 AM
aemerson committed rGe6ed880e4757: [AArch64][GlobalISel] Make some vector G_SMULH/G_UMULH legal. (authored by aemerson).
[AArch64][GlobalISel] Make some vector G_SMULH/G_UMULH legal.
Sep 29 2021, 2:35 AM

Sep 28 2021

aemerson added inline comments to D107160: [AArch64] Do not emit an extra zero-extend for i1 argument.
Sep 28 2021, 5:40 PM · Restricted Project