Page MenuHomePhabricator

void (Bill Wendling)
Mind Taker

Projects

User does not belong to any projects.

User Details

User Since
Dec 3 2012, 10:22 AM (407 w, 11 h)

Sent here from the planet Zvddw, Bill's mission is to conquer the world by staying at home and occasionally (read: always) playing poker.

In his spare time, he works on LLVM-related things.

Recent Activity

Thu, Sep 17

void added inline comments to D87865: PR47468: Fix findPHICopyInsertPoint, so that copies aren't incorrectly inserted after an INLINEASM_BR..
Thu, Sep 17, 4:36 PM · Restricted Project

Aug 20 2020

void updated the summary of D86260: [CodeGen] Postprocess PHI nodes for callbr.
Aug 20 2020, 6:20 PM · Restricted Project
void added a comment to D86260: [CodeGen] Postprocess PHI nodes for callbr.

The commit message is confusing for this -- this isn't a correctness fix, but a minor optimization, right?

I'm not convinced it's just an optimization, but I could be swayed. It seems to me that the value coming into the PHI shouldn't rely upon the semantics of the asm block. So for instance would this be incorrect?

Inline assembly must declare what registers it clobbers, and the compiler can safely assume other registers are preserved across it.

bb1:
  %eax = MOV 0
  INLINEASM_BR "mov 37, %eax"
  JMP return

return:
  PHI bb1, 0 ...

So, in this example the input inline-asm is invalid, because it failed to declare that it clobbered eax.

Aug 20 2020, 6:19 PM · Restricted Project
void added inline comments to D85849: [X86] Flatten feature dependency tree at compile-time.
Aug 20 2020, 5:55 PM · Restricted Project
void added a comment to D86260: [CodeGen] Postprocess PHI nodes for callbr.

The commit message is confusing for this -- this isn't a correctness fix, but a minor optimization, right?

Aug 20 2020, 3:28 PM · Restricted Project
void added inline comments to D86260: [CodeGen] Postprocess PHI nodes for callbr.
Aug 20 2020, 1:15 PM · Restricted Project
void updated the diff for D86260: [CodeGen] Postprocess PHI nodes for callbr.

Remove extraneous thread_local from global variable.

Aug 20 2020, 1:15 PM · Restricted Project

Aug 19 2020

void requested review of D86260: [CodeGen] Postprocess PHI nodes for callbr.
Aug 19 2020, 7:58 PM · Restricted Project

Jul 23 2020

void added a comment to D75098: Add TCOPY, a terminator form of the COPY instr.

What's the status of this? I'm still interested in terminator copies

Jul 23 2020, 12:19 PM · Restricted Project

Jul 15 2020

void accepted D83708: Remove TwoAddressInstructinoPass::sink3AddrInstruction..

LGTM

Jul 15 2020, 1:05 PM · Restricted Project

Jul 12 2020

void added a comment to D83523: MachineSink: permit sinking into INLINEASM_BR indirect targets.

Here are a few other places to contemplate similar changes:

Jul 12 2020, 8:03 PM · Restricted Project
void added a comment to D83523: MachineSink: permit sinking into INLINEASM_BR indirect targets.

I think this might be a better fix:

Jul 12 2020, 7:54 PM · Restricted Project

Jul 10 2020

void added a comment to D83523: MachineSink: permit sinking into INLINEASM_BR indirect targets.

Without this change, the "ADD64ri8" instruction is before the INLINEASM_BR before machine sinking.

Jul 10 2020, 2:33 PM · Restricted Project

Jul 9 2020

void added a comment to D83523: MachineSink: permit sinking into INLINEASM_BR indirect targets.

I'm confused by this change. The original code *should* be correct. That it's resulting in this issue is another thing.

Jul 9 2020, 6:07 PM · Restricted Project

Jun 29 2020

void added inline comments to D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction..
Jun 29 2020, 2:46 PM · Restricted Project
void added a comment to D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction..

The only other concern I have is whether we have enough test coverage of the scheduling boundary changes? (Does removing the added checks there cause any existing or new test from the change to file? If not, seems like a lack of test coverage.) In the case of PostRASchedulerList, that implies a MIR test (writing MIR tests isn't something I'd wish on my worst enemy though).

Jun 29 2020, 2:46 PM · Restricted Project

Jun 26 2020

void accepted D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction..

Thanks! :-)

Jun 26 2020, 6:09 PM · Restricted Project

Jun 22 2020

void added a comment to D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction..

@void that diff on top of this revision resolves the issue I was seeing, thanks!

That's great! @void is there a test case we can add for that post RA schedule, so that we don't regress that? @jyknight would you mind rolling @void 's changes up into this and rebasing, please? I'm curious if there's anything we can do to combine isSchedBoundary and isSchedulingBoundary?

Jun 22 2020, 3:35 PM · Restricted Project

Jun 21 2020

void added a comment to D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction..

@nathanchance & @nickdesaulniers: I forgot the post scheduler. Try the patch below.

Jun 21 2020, 4:45 AM · Restricted Project

Jun 16 2020

void added a comment to D81632: Fix undefined behavior in PeepholeOptimizer..

Which platform did you run valgrind on? The x86 platform should set SubIdx on all paths through it...

ARM. armv8-linux-android.

Jun 16 2020, 12:39 PM · Restricted Project

Jun 15 2020

void added a comment to D81632: Fix undefined behavior in PeepholeOptimizer..

I think SubIdx is supposed to be set by TII->isCoalescableExtInstr(). If it's not doing that, then the error's probably in that call and not in this function.

Then most target instr infos need to patch.

A test case that shows the problem would also be good.

valgrind shows me this bug. I don't think any testcase is able to reproduce an expected value in this circumstance.

Jun 15 2020, 7:19 PM · Restricted Project

Jun 14 2020

void added a comment to D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction..

I think you need the following patch. We shouldn't allow instructions to be rescheduled after an INLINEASM_BR, because all values who's definition dominate the INLINEASM_BR are assumed to be valid on the indirect branch.

Jun 14 2020, 9:51 PM · Restricted Project

Jun 12 2020

void added inline comments to D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction..
Jun 12 2020, 11:25 PM · Restricted Project
void added a comment to D81607: BreakCriticalEdges for callbr indirect dests.

While it's not the case right now, I think it would be very desirable to allow this in the future for callbr. Some of the other envisioned use-cases for callbr would require the ability to pass the target block in as a value (in which case there may be no blockaddress arguments directly on the callbr.)

Being indecisive about this is creating a mess in both the LLVM IR and MachineInstrs. I've repeatedly asked about this, and gotten contradictory answers every time. We need to make a decision here and stick to it.

Jun 12 2020, 6:48 PM · Restricted Project
void added a comment to D81607: BreakCriticalEdges for callbr indirect dests.

Disclaimer: I don't plan to rework callbr's operands before landing this. Was that a conditional LGTM?

Wasn't intended to be conditional on any code changes. Just that we don't plan to ever allow jumping to blockaddresses passed in as register operands.

I assume there's something important @fhahn was alluding to, but I'm not sure precisely what, and I would like to make sure everyone's happy with this.

The reason we can't split edges coming out of indirectbr instructions is that in general, there is no way to fix the related blockaddresses in functions that contain multiple indirectbrs. We can't rename the successor in one indirectbr without renaming it in all of them. And if we rename it in all of them, the edge is still critical after the transform.

We want to be sure the same issue doesn't apply to callbr instructions. If it does, then we would need to fix the callers of SplitCriticalEdge, not SplitCriticalEdge itself.

Wait, that sounds like a problem. Imagine we have 3 callbrs, two that share the same indirect destination, and we decide to split one their critical edges. Then we update the blockaddress of that callbr, but not the others where the others' indirect branch now doesn't preserve the previous operations. As if we added another callbr in the entry of this test case with an indirect destination of %CallSiteBB.

Jun 12 2020, 6:48 PM · Restricted Project
void added a comment to D81607: BreakCriticalEdges for callbr indirect dests.

If the plan is to drop blockaddresses from callbr, then this LGTM.

Disclaimer: I don't plan to rework callbr's operands before landing this. Was that a conditional LGTM?

I would like to resolve @fhahn 's question. TBH, I understand what a critical edge is, but I don't understand why splitting them is necessary? I assume there's something important @fhahn was alluding to, but I'm not sure precisely what, and I would like to make sure everyone's happy with this.

Jun 12 2020, 1:42 PM · Restricted Project
void added a comment to D81632: Fix undefined behavior in PeepholeOptimizer..

I think SubIdx is supposed to be set by TII->isCoalescableExtInstr(). If it's not doing that, then the error's probably in that call and not in this function.

Jun 12 2020, 1:08 PM · Restricted Project

Jun 10 2020

void added inline comments to D81607: BreakCriticalEdges for callbr indirect dests.
Jun 10 2020, 12:13 PM · Restricted Project

Jun 3 2020

void added a comment to D79605: MachineBasicBlock::updateTerminator now requires an explicit layout successor..

Is this and D79793 ready for submission? :-)

Jun 3 2020, 1:46 PM · Restricted Project

Jun 1 2020

void added a comment to D79605: MachineBasicBlock::updateTerminator now requires an explicit layout successor..

Is this and D79793 ready for submission? :-)

Jun 1 2020, 1:33 AM · Restricted Project

May 28 2020

void added inline comments to D80745: [DAGCombiner] Add a command line option to guard ReduceLoadOpStoreWidth.
May 28 2020, 3:59 PM · Restricted Project
void added a comment to D75098: Add TCOPY, a terminator form of the COPY instr.

Regardless of what happens to INLINEASM_BR, I think we still need a terminator copy

What for?
The whole concept is bogus to me because if the previous instructions are really terminators (as in they branch to somewhere else), then this copy would never be executed.

May 28 2020, 3:45 AM · Restricted Project

May 21 2020

void added a comment to D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction..

Quick ping to ask about the status of this change. :-)

May 21 2020, 1:32 PM · Restricted Project

May 12 2020

void added a comment to D79794: Change the INLINEASM_BR MachineInstr to be a non-terminating instruction..

I think we should rename INLINEASM_BR to something that doesn't involve the _BR bit, since it's no longer a branch.

May 12 2020, 7:24 PM · Restricted Project
void added a comment to D75098: Add TCOPY, a terminator form of the COPY instr.

I think the better fix here is to make INLINEASM_BR _not_ be a terminator -- just like the CALL involved in an invoke is not.

That change turned out to be a bit complicated, and while I had started taking a stab at that a couple months ago, I got distracted by many other things going on...However, I've now dusted off that experiment and got it into a useful state, and will send out a review for this tomorrow, so we can consider both the options.

May 12 2020, 6:52 PM · Restricted Project

May 10 2020

void added a comment to D75098: Add TCOPY, a terminator form of the COPY instr.

Thanks Bill for the detailed explanations. A couple more questions.

CodeGen wants registers to be spilled at the end of a block.

That's fast reg alloc only. What is happening with the other allocators?

They don't appear to use the correct registers for the defined values.

I should probably explain a bit better. With a normal INLINEASM instruction, any defined registers are spilled directly afterwards. This is one reason why I want to do the same for INLINEASM_BR with the TCOPY. There could be other ways to achieve the same thing, but I think it would involve placing a larger burden on the code generation passes than needs be.

May 10 2020, 11:57 PM · Restricted Project
void updated the diff for D75098: Add TCOPY, a terminator form of the COPY instr.

Revert bad formatting that sneaked (snuck?) in.

May 10 2020, 3:11 AM · Restricted Project

May 9 2020

void updated the diff for D75098: Add TCOPY, a terminator form of the COPY instr.

Fix formatting and clang-tidy warnings.

May 9 2020, 3:41 AM · Restricted Project
void updated the diff for D75098: Add TCOPY, a terminator form of the COPY instr.

Spill TCOPY in FastRA right before the TCOPY instr instead of before the
terminators.

May 9 2020, 2:05 AM · Restricted Project

May 8 2020

void added inline comments to D75098: Add TCOPY, a terminator form of the COPY instr.
May 8 2020, 4:41 PM · Restricted Project
void updated the diff for D75098: Add TCOPY, a terminator form of the COPY instr.

Allow a TCOPY to sink, since it's exactly like a COPY.

May 8 2020, 2:31 PM · Restricted Project
void updated the diff for D75098: Add TCOPY, a terminator form of the COPY instr.

Remove some of the hackery in the SDNode scheduler that splits below an
INLINEASM_BR instruction. It's not needed with TCOPY.

May 8 2020, 4:47 AM · Restricted Project

May 7 2020

void added a comment to D75098: Add TCOPY, a terminator form of the COPY instr.

Thanks Bill for the detailed explanations. A couple more questions.

CodeGen wants registers to be spilled at the end of a block.

That's fast reg alloc only. What is happening with the other allocators?

May 7 2020, 7:32 PM · Restricted Project

May 4 2020

void added a comment to D75098: Add TCOPY, a terminator form of the COPY instr.

I don't think introducing the TCOPY opcode is a valid solution.
Let's assume the copy doesn't get coalesced, that means it needs to be executed after the inlineasm branch. And this is not going to happen if it sits in the same basic block right after the jump.

What happens if you put the copy at the beginning of each successor?
You mentioned that this is not possible because the live-ins wouldn't be set, but I would expect that this information would be correctly computed when building the liveness information. I.e., I don't expect this to be a problem.

we allow a store of a physical register after the INLINEASM_BR when optimizations are disabled.

That sounds wrong.

Could we step back a little bit, what is the semantic of INLINEASM_BR?

May 4 2020, 3:37 PM · Restricted Project
void updated the diff for D75098: Add TCOPY, a terminator form of the COPY instr.
  • Add support to MIR parsing.
  • Rebase current change.
May 4 2020, 3:42 AM · Restricted Project
void added inline comments to D75098: Add TCOPY, a terminator form of the COPY instr.
May 4 2020, 3:41 AM · Restricted Project

May 2 2020

void added a comment to D77849: [calcspillweights] mark LiveIntervals from INLINEASM_BR defs as not spillable.

branch-folder should probably assert when removing a MachineBasicBlock that has its address taken.

My convcern here is that we aren't very aggressive about dropping blockaddresses at the IR level, so we could end up with an "address-taken" block that doesn't actually have any callbr/indirectbr predecessors.

May 2 2020, 5:16 AM · Restricted Project
void added inline comments to D79055: [LiveVariables] Mark PhysReg implicit-def MachineOperands of INLINEASM_BR as LiveOut.
May 2 2020, 5:16 AM · Restricted Project

Apr 19 2020

void committed rGedcfc391e142: [Object] Use BFD name for little-endian PowerPC64 (authored by void).
[Object] Use BFD name for little-endian PowerPC64
Apr 19 2020, 8:17 PM
void closed D78344: [Object] Use BFD name for little-endian PowerPC64.
Apr 19 2020, 8:17 PM · Restricted Project, Restricted Project
void added a comment to D78344: [Object] Use BFD name for little-endian PowerPC64.

See D76046 . elf64-powerpc64le is called a BFD name (or bfdname)

Apr 19 2020, 4:01 PM · Restricted Project, Restricted Project

Apr 16 2020

Herald added a reviewer for D78344: [Object] Use BFD name for little-endian PowerPC64: alexshap.
Apr 16 2020, 8:33 PM · Restricted Project, Restricted Project

Apr 6 2020

void accepted D77600: [CallSite Removal] a CallBase is never an IndirectCall for isInlineAsm.
Apr 6 2020, 3:48 PM · Restricted Project

Apr 3 2020

void accepted D77356: [test] preformat test with update_llc_test_checks.py NFC.
Apr 3 2020, 12:25 PM · Restricted Project

Apr 2 2020

void added a comment to D76961: [SelectionDAG] fix predecessor list for INLINEASM_BRs' parent.

@void would you be opposed to me posting a patch first that preprocessed llvm/test/CodeGen/X86/callbr-asm-outputs.ll with llvm/utils/update_llc_test_checks.py?

I find updating these tests with lots of checks to be a PITA, and it make it easier to maintain this test in the future and see what changed easier with my change.

Yeah, go for it.

huh, so it seems that ./llvm/utils/update_llc_test_checks.py llvm/test/CodeGen/X86/callbr-asm-outputs-pred-succ.ll doesn't actually do anything :( so I don't think I can preprocess it. I think the output needs to change; I don't understand how you write a test that update_llc_test_checks.py is happy with off of the bat.

Special talent. :-)

Apr 2 2020, 8:04 PM · Restricted Project
void added a comment to D76961: [SelectionDAG] fix predecessor list for INLINEASM_BRs' parent.

Ok, everything is green now, kernel boots. (There's probably more verification I can do, too).

@void would you be opposed to me posting a patch first that preprocessed llvm/test/CodeGen/X86/callbr-asm-outputs.ll with llvm/utils/update_llc_test_checks.py?

I find updating these tests with lots of checks to be a PITA, and it make it easier to maintain this test in the future and see what changed easier with my change.

Apr 2 2020, 5:54 PM · Restricted Project

Mar 31 2020

void updated subscribers of D62627: [NFC] Do not run CGProfilePass when not using integrated assembler.

Friendly ping. :-)

Mar 31 2020, 2:42 AM · Restricted Project, Restricted Project

Mar 30 2020

void committed rGfa496ce3c677: [Intrinsic] Give "is.constant" the "convergent" attribute (authored by void).
[Intrinsic] Give "is.constant" the "convergent" attribute
Mar 30 2020, 11:58 AM
void closed D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.
Mar 30 2020, 11:58 AM · Restricted Project
void retitled D75799: [Intrinsic] Give "is.constant" the "convergent" attribute from [JumpThreading] Don't create PHI nodes with "is.constant" values to [Intrinsic] Give "is.constant" the "convergent" attribute.
Mar 30 2020, 11:56 AM · Restricted Project
void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Please revisit patch title/description before commiting

Mar 30 2020, 11:56 AM · Restricted Project

Mar 29 2020

void updated the diff for D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Using a convergent attribute accomplishes the same thing and doesn't run into the issue Eli pointed out, which is that we're creating special rules for passes.

Mar 29 2020, 9:24 PM · Restricted Project
void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

@kazu and @MaskRay I modified this to just add the "convergent" attribute to is.constant. It seems to be just fine for it. PTAL.

Mar 29 2020, 9:24 PM · Restricted Project
void added inline comments to D73422: [IR] Delete MODULE_CODE_DEPLIB.
Mar 29 2020, 7:48 PM · Restricted Project

Mar 27 2020

void accepted D76961: [SelectionDAG] fix predecessor list for INLINEASM_BRs' parent.

Good catch.

Mar 27 2020, 6:12 PM · Restricted Project

Mar 26 2020

void added inline comments to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.
Mar 26 2020, 1:35 AM · Restricted Project

Mar 24 2020

void added reviewers for D75799: [Intrinsic] Give "is.constant" the "convergent" attribute: kazu, MaskRay.
Mar 24 2020, 4:30 PM · Restricted Project

Mar 23 2020

void added inline comments to D76206: [gcov] Fix simultaneous .gcda creation.
Mar 23 2020, 12:33 PM · Restricted Project

Mar 20 2020

void added inline comments to D74809: [MBP][X86] Include static prof data when collecting loop BBs.
Mar 20 2020, 3:45 PM · Restricted Project
void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

The original code has a functional dependency between sz and bytes and whether they can be constant evaluated. But the code doesn't express that. I don't think we can enforce that in any sensible way. There are valid use cases after all where partial inlining would result in entirely sensible decisions, just think about the more typical case of __builtin_constant_p selecting between inline asm taking immediate operands and one taking register/memory operands. That's why I am saying that I consider it a lot more useful to provide reliable building blocks to express the dependency and make sure they work.

Mar 20 2020, 1:01 PM · Restricted Project

Mar 19 2020

void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Yes, builtin_expect is just noise here. The point I wanted to make is that both sz and bytes should be used in builtin_constant_p in the other condition.

Mar 19 2020, 9:54 PM · Restricted Project
void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

IMO the root of the problem here is that the branches are mixing predicated variables (bytes) with non-predicated variables (sz). If users want deterministic behavior here, that shouldn't be done.

Mar 19 2020, 12:32 PM · Restricted Project

Mar 18 2020

void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

I was discussing this with Bill off-list to get a better idea of the original test case. Basically, with the new constant intrinsic pass, we can provide a stronger semantic: the default LLVM pass chain always constant folds expressions involving is.constant and performs DCE trivially dead branches resulting from the former folding. This means that if the original expression is adjusted from:

if (__builtin_expect(!!(sz >= 0 && sz < bytes), 0)) {
    if (!__builtin_constant_p(bytes))
    ...
}

to the functionally equivalent:

if (!(__builtin_constant_p(sz) && __builtin_constant_p(bytes) && sz >= 0 && sz >= bytes) && __builtin_expect(!!(sz >= 0 && sz < bytes), 0)) {
    if (!__builtin_constant_p(bytes))
    ...
}

then we can actually ensure proper DCE even with -O0 in the default pass chain. That depends over all on two properties:

  • If __builtin_constant_p is constant folded by clang, it must DCE the appropiate places.
  • the constant intrinsic pass is run

With -O1 or higher, this should work in general.

Mar 18 2020, 7:00 PM · Restricted Project
void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

I'm not really happy about imposing optimization "rule", which we have to follow for correctness, without some explanation in LangRef. Hacking a specific pass without a general rule is just going to make things more messy in the future; some other pass will eventually trip over this, and we won't have any reference for how it should be fixed.

Really, to preserve the semantics the kernel wants in general, we need some notion of a "region": when we have an if statement with a builtin_constant_p condition, the body of that if statement is a region with special semantics. If we resolve a builtin_constant_p, every use of a variable used as an input to the __builtin_constant_p must be constant-folded inside that region. We can optimize within the region, we can clone the whole region, but we can't clone the entry point of the region without cloning the whole thing, and we can't merge parts of the region without merging the whole thing.

I'm not sure how to actually represent that in LLVM IR in a way that can be uniformly queried by optimizations in a reasonable way. I guess marking llvm.is.constant "convergent" partially solves the issue, but we still might have problems with optimizations that merge code.

Mar 18 2020, 7:00 PM · Restricted Project
void added a comment to D75098: Add TCOPY, a terminator form of the COPY instr.

Another friendly ping. :-)

Mar 18 2020, 3:13 PM · Restricted Project
void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Another friendly ping. :-)

Mar 18 2020, 3:13 PM · Restricted Project

Mar 15 2020

void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Friendly ping. :-)

Mar 15 2020, 3:32 PM · Restricted Project
void added a comment to D75098: Add TCOPY, a terminator form of the COPY instr.

Friendly ping. :-)

Mar 15 2020, 3:32 PM · Restricted Project
void updated the diff for D75098: Add TCOPY, a terminator form of the COPY instr.

Rebase and update testcase.

Mar 15 2020, 3:32 PM · Restricted Project

Mar 13 2020

void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Can you post standalone example on godbolt that shows this link failure without this patch please?

I'm not sure what that will achieve. It would include all of the Linux kernel as part of the linking process, and it's only one file (the one I reduced the testcase from) that has the __bad_copy_from() reference still in it. Perhaps I'm missing something?

I personally still don't understand *why* after this transform we fail to DCE. Is this pass ordering issue? Heuristics issue?

Mar 13 2020, 5:06 AM · Restricted Project

Mar 12 2020

void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Can you post standalone example on godbolt that shows this link failure without this patch please?

Mar 12 2020, 7:04 PM · Restricted Project
void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Friendly ping. :-)

Mar 12 2020, 2:07 PM · Restricted Project
void updated the diff for D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

s/IsUsedBy/isUsedBy/g

Mar 12 2020, 2:07 PM · Restricted Project

Mar 11 2020

void committed rG6aebf0ee56e5: Specify branch probabilities for callbr dests (authored by void).
Specify branch probabilities for callbr dests
Mar 11 2020, 9:07 PM
void closed D72656: Specify branch probabilities for callbr dests.
Mar 11 2020, 9:07 PM · Restricted Project
void added a comment to D72656: Specify branch probabilities for callbr dests.

PTAL.

Mar 11 2020, 6:20 PM · Restricted Project
void updated the diff for D72656: Specify branch probabilities for callbr dests.

Run update_llc_test_checks.py on the testcase.

Mar 11 2020, 6:20 PM · Restricted Project
void added inline comments to D72656: Specify branch probabilities for callbr dests.
Mar 11 2020, 6:10 PM · Restricted Project
void updated the diff for D72656: Specify branch probabilities for callbr dests.

Rebase patch.

Mar 11 2020, 6:10 PM · Restricted Project

Mar 10 2020

void added inline comments to D75098: Add TCOPY, a terminator form of the COPY instr.
Mar 10 2020, 5:00 PM · Restricted Project
void committed rG218dd339541f: Add triple for non-x86 environments. (authored by void).
Add triple for non-x86 environments.
Mar 10 2020, 3:54 PM
void committed rG72aa619a7fe0: Warn of uninitialized variables on asm goto's indirect branch (authored by void).
Warn of uninitialized variables on asm goto's indirect branch
Mar 10 2020, 2:16 PM
void closed D71314: Warn of uninitialized variables on asm goto's indirect branch.
Mar 10 2020, 2:15 PM · Restricted Project
void updated the diff for D75098: Add TCOPY, a terminator form of the COPY instr.

Add TCOPY to some switch statements that handle COPY

Mar 10 2020, 1:39 PM · Restricted Project
void added a comment to D71314: Warn of uninitialized variables on asm goto's indirect branch.

Friendly ping. :-)

Mar 10 2020, 5:48 AM · Restricted Project

Mar 9 2020

void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

It still seems to be a perfectly reasonable optimisation under the semantics of is.constant. The code here seems to be an abuse of it though and makes assumptions that are not sensible.

Mar 9 2020, 2:36 PM · Restricted Project
void updated the diff for D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Make test more representative of what this patch is doing.

Mar 9 2020, 2:35 PM · Restricted Project
void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

I'm confused by that example. If jumpthreading makes it possible to answer true, it is no differerent from inlining and other use cases. The reverse is the problematic case, turning constant cases into non-constant cases?

Mar 9 2020, 1:30 PM · Restricted Project
void updated the diff for D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

Reformat and test fix.

Mar 9 2020, 12:25 PM · Restricted Project
void added a comment to D75799: [Intrinsic] Give "is.constant" the "convergent" attribute.

This is after jump threading:

Are you sure that is the correct snippet? Because if it is, i'm lost completely.

Yes. I just elided some parts that aren't super relevant. I can supply a preprocessed file though.

Mar 9 2020, 12:25 PM · Restricted Project