Page MenuHomePhabricator
Feed Advanced Search

Thu, Oct 22

void added a comment to D87956: [IR] add fn attr for no_stack_protector; prevent inlining on mismatch.

In phab here, it looks like my newly added clang/test/Frontend/optimization-remark-missed-inline-stack-protectors.c fails on windows because I redirect stdout to /dev/null. How does that work for other tests? I see other tests in that dir write to /dev/null. Oh, I guess -o /dev/null will just create a file called "/dev/null" on Windows? So I should do that rather than 1> /dev/null?

Thu, Oct 22, 2:06 PM · Restricted Project, Restricted Project

Wed, Oct 21

void accepted D87956: [IR] add fn attr for no_stack_protector; prevent inlining on mismatch.

Only a couple of nits, but I think this looks good.

Wed, Oct 21, 3:44 PM · Restricted Project, Restricted Project

Tue, Oct 20

void added inline comments to D87956: [IR] add fn attr for no_stack_protector; prevent inlining on mismatch.
Tue, Oct 20, 8:12 PM · Restricted Project, Restricted Project

Tue, Oct 6

void committed rGd2c61d2bf9bd: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR (authored by void).
[CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR
Tue, Oct 6, 6:45 PM
void closed D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.
Tue, Oct 6, 6:45 PM · Restricted Project
void updated the diff for D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

Rerun with the correct llc.

Tue, Oct 6, 6:08 PM · Restricted Project
void updated the diff for D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

Update comment and testcase.

Tue, Oct 6, 5:59 PM · Restricted Project
void updated the summary of D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.
Tue, Oct 6, 4:11 PM · Restricted Project
void reclaimed D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

Okay. Abandoning this change.

Sorry, maybe I buried the lede too far into the message? "I think the fix you have here is OK" was at the end. :)

One thing, I believe we're trying to turn "asm goto" into something it was never meant to be. If you look at gcc's output for this code.

Okay. I'll reclaim this revision.

Tue, Oct 6, 4:05 PM · Restricted Project

Mon, Oct 5

void added a comment to D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

One thing, I believe we're trying to turn "asm goto" into something it was never meant to be. If you look at gcc's output for this code:

Mon, Oct 5, 11:50 PM · Restricted Project
void added a comment to D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

Okay. Abandoning this change.

Mon, Oct 5, 11:29 PM · Restricted Project
void abandoned D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.
Mon, Oct 5, 11:26 PM · Restricted Project
void added a comment to D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

Here are the relevant parts of the original issue in get_partial_node. Blocks bb.16.bb100 and bb.17.bb106 are the sources of the values in the PHI node in bb.18.bb110. The bb.19.bb17.i.i.i block is the indirect destination and bb.20.bb113 the default destination.

Mon, Oct 5, 8:21 PM · Restricted Project
void added a comment to D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

When we go to resolve this PHI node, there's no place to put the put the values that works in all situations; we can't split the critical edges and it's not valid to place the resolved instructions at the ends of the predecessor blocks.

We can (at least: should be able to) handle a PHI node in the indirect targets of an INLINEASM_BR, for any value which is not the output of the INLINEASM_BR itself. We place the required register copies prior to the INLINEASM_BR, rather than after it. This is handled by findPHICopyInsertPoint -- where we did have a bug already, fixed in f7a53d82c0902147909f28a9295a9d00b4b27d38.

Mon, Oct 5, 7:58 PM · Restricted Project
void added a comment to D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

%9:gr32 = PHI %0:gr32, %bb.1, %5:gr32, %bb.2

The problem is this PHI here. We don't have a way to resolve PHI nodes in the entry block to an indirect destination. (This is the reason we don't allow "asm goto" outputs on the indirect paths.) When we go to resolve this PHI node, there's no place to put the put the values that works in all situations; we can't split the critical edges and it's not valid to place the resolved instructions at the ends of the predecessor blocks.

We're also not using "asm goto" outputs in this test case, so I still don't understand why this PHI is problematic.

That doesn't matter. It's problematic because of the PHI in the block with the INLINEASM_BR. As I mentioned, the result of the tail duplication is that that PHI is more-or-less moved *down* into the indirect and default destinations. Look at those PHIs and you'll see that they have the same values coming into them.

Mon, Oct 5, 7:52 PM · Restricted Project
void added a comment to D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

I confirmed that this patch does fix the kernel panic observed in https://github.com/ClangBuiltLinux/linux/issues/1125#issuecomment-703890483.

I don't understand the bug though. Looking at the output of:

llc -mtriple=i686-- -stop-after=early-tailduplication -print-after-all llvm/test/CodeGen/X86/tail-dup-asm-goto.ll -o - 2>&1 | less

Before/After IR Dump After Early Tail Duplication before rebuilding clang with this patch applied (so still in a bad state), but nothing looks wrong to me. So what precisely is the bug?

Before early tail dup:

bb.0.bb:
  successors: %bb.1(0x40000000), %bb.2(0x40000000); %bb.1(50.00%), %bb.2(50.00%)

  %2:gr32 = IMPLICIT_DEF
  %0:gr32 = MOV32rm killed %2:gr32, 1, $noreg, 0, $noreg :: (load 4 from `i8** undef`, align 8)
  %3:gr32_abcd = MOV32r0 implicit-def dead $eflags
  %4:gr8 = COPY %3.sub_8bit:gr32_abcd
  TEST8rr %4:gr8, %4:gr8, implicit-def $eflags
  JCC_1 %bb.2, 5, implicit $eflags
  JMP_1 %bb.1

bb.1.bb100:
; predecessors: %bb.0
  successors: %bb.3(0x80000000); %bb.3(100.00%)

  %6:gr32 = IMPLICIT_DEF
  MOV32mi killed %6:gr32, 1, $noreg, 0, $noreg, 0 :: (store 4 into `i8** undef`, align 8)
  JMP_1 %bb.3

bb.2.bb106:
; predecessors: %bb.0
  successors: %bb.3(0x80000000); %bb.3(100.00%)

  ADJCALLSTACKDOWN32 0, 0, 0, implicit-def dead $esp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $esp, implicit $ssp
  CALLpcrel32 @foo, <regmask $bh $bl $bp $bph $bpl $bx $di $dih $dil $ebp $ebx $edi $esi $hbp $hbx $hdi $hsi $si $sih $sil>, implicit $esp, implicit $ssp, implicit-def $esp, implicit-def 
$ssp
  ADJCALLSTACKUP32 0, 0, implicit-def dead $esp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $esp, implicit $ssp
  %5:gr32 = MOV32r0 implicit-def dead $eflags

bb.3.bb110:
; predecessors: %bb.2, %bb.1
  successors: %bb.5(0x80000000), %bb.4(0x00000000); %bb.5(100.00%), %bb.4(0.00%)

  %1:gr32 = PHI %5:gr32, %bb.2, %0:gr32, %bb.1
Mon, Oct 5, 2:57 PM · Restricted Project
void added a comment to D88813: [CodeGen] Postprocess PHI nodes for callbr.

test case looks reasonable (I haven't run it pre-patch to see what goes wrong yet). Just curious, is this CL related to D88823?

Mon, Oct 5, 1:24 PM · Restricted Project
void updated the summary of D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.
Mon, Oct 5, 12:40 PM · Restricted Project
void added a comment to D88813: [CodeGen] Postprocess PHI nodes for callbr.

@jyknight This doesn't have the loop refactored like you asked for. I'll work on that today.

Mon, Oct 5, 12:37 PM · Restricted Project
void updated the diff for D88813: [CodeGen] Postprocess PHI nodes for callbr.

Update with missing elements so that it works.

Mon, Oct 5, 12:36 PM · Restricted Project
void added a comment to D88813: [CodeGen] Postprocess PHI nodes for callbr.

test?

Mon, Oct 5, 12:31 PM · Restricted Project
void updated the diff for D88813: [CodeGen] Postprocess PHI nodes for callbr.

Add testcase.

Mon, Oct 5, 12:31 PM · Restricted Project
void updated the diff for D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

Add testcase.

Mon, Oct 5, 11:10 AM · Restricted Project
void updated the diff for D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

Improve comment on why we're limiting tail duplication on INLINEASM_BR instruction.

Mon, Oct 5, 10:08 AM · Restricted Project
void added a comment to D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.

Hm, it doesn't seem like it should be a problem to duplicate an inlineasm_br instruction. I'm interested to see what's going wrong here.

Mon, Oct 5, 10:01 AM · Restricted Project
void requested review of D88823: [CodeGen][TailDuplicator] Don't duplicate blocks with INLINEASM_BR.
Mon, Oct 5, 4:24 AM · Restricted Project
void requested review of D88813: [CodeGen] Postprocess PHI nodes for callbr.
Mon, Oct 5, 2:37 AM · Restricted Project

Wed, Sep 30

void added a comment to D88438: BreakCriticalEdges: bail if loop-simplify form requested for CallBr terminated BB.

I believe that a critical edge may be split on the default path, but not the indirect path.

I don't think https://github.com/llvm/llvm-project/commit/2fe457690da0fc38bc7f9f1d0aee2ba6a6a16ada made a similar distinction?

Yeah. I made an error there...

Wed, Sep 30, 7:23 PM · Restricted Project
void added a comment to D88438: BreakCriticalEdges: bail if loop-simplify form requested for CallBr terminated BB.

The concept of splitting a critical edge is still relatively new to me; any thoughts on *why* it would not be ok to split a critical branch of an indirect-like jump?

The problem has to do with blockaddress.

For normal branches, splitting an edge is usually straightforward: you just introduce a new block that branches to the original block, and then you rewrite the branch in the predecessor. But suppose you have a block with two indirectbr predecessors, and you want to split the edge. In that case, the "rewrite the branch" step doesn't work: you can't rewrite the address argument to the indirectbr. (Or at least, you can't without performing some invasive rewrite like indirectbr->switch lowering.)

Wed, Sep 30, 7:18 PM · Restricted Project
void added a comment to D88438: BreakCriticalEdges: bail if loop-simplify form requested for CallBr terminated BB.

I believe that a critical edge may be split on the default path, but not the indirect path.

Wed, Sep 30, 4:34 PM · Restricted Project
void added inline comments to D87956: [IR] add fn attr for no_stack_protector; prevent inlining on mismatch.
Wed, Sep 30, 3:17 AM · Restricted Project, Restricted Project

Sep 24 2020

void committed rGc9b53b3bf20d: Fix regex in test. (authored by void).
Fix regex in test.
Sep 24 2020, 3:21 PM
void added a comment to D86260: [CodeGen] Postprocess PHI nodes for callbr.

Erm...Reverted...Sorry.

Sep 24 2020, 2:36 PM · Restricted Project
void added a reverting change for D86260: [CodeGen] Postprocess PHI nodes for callbr: rG0c0c57f7b21b: Revert "[CodeGen] Postprocess PHI nodes for callbr".
Sep 24 2020, 2:36 PM · Restricted Project
void added a reverting change for rG7f4c940bd0b5: [CodeGen] Postprocess PHI nodes for callbr: rG0c0c57f7b21b: Revert "[CodeGen] Postprocess PHI nodes for callbr".
Sep 24 2020, 2:36 PM
void committed rG0c0c57f7b21b: Revert "[CodeGen] Postprocess PHI nodes for callbr" (authored by void).
Revert "[CodeGen] Postprocess PHI nodes for callbr"
Sep 24 2020, 2:35 PM
void committed rGf97b68ef4ddd: Fix testcase. (authored by void).
Fix testcase.
Sep 24 2020, 2:35 PM
void committed rG7f4c940bd0b5: [CodeGen] Postprocess PHI nodes for callbr (authored by void).
[CodeGen] Postprocess PHI nodes for callbr
Sep 24 2020, 2:34 PM
void closed D86260: [CodeGen] Postprocess PHI nodes for callbr.
Sep 24 2020, 2:34 PM · Restricted Project
void committed rG34ca5b3392ce: Remove stale assert. (authored by void).
Remove stale assert.
Sep 24 2020, 2:00 PM
void closed D88195: Remove stale assert..
Sep 24 2020, 1:59 PM · Restricted Project
void updated the summary of D88195: Remove stale assert..
Sep 24 2020, 1:55 PM · Restricted Project
void updated the diff for D88195: Remove stale assert..

Clarify commit message.

Sep 24 2020, 1:30 PM · Restricted Project
void added a comment to D88195: Remove stale assert..

I'm super confused between the commit message and initial hunk, that seem to make sense and probably should go in clang-11 if it's not too late, and the additional tests for modules which the commit message does not address. Were these meant to be separate commits, because otherwise it looks like you uploaded unrelated stuff. Are C++20 modules broken with asm goto, or are you just adding additional test coverage for that?

The assert only triggers for modules, so yeah modules are broken with "asm goto", but only if asserts are enabled.

The assert was removed from AST/Stmt.cpp; it doesn't look module related. Wouldn't it be triggered by ANY GCCAsmStmt? (I have patches that use ASM goto w/ outputs on the kernel, let me try an assertions enabled build). It's not obvious to me why the method modified would only trigger for modules.

Yes, but that particular function is only called during serialization reading. It would trigger for any serialization, this just happens to be for modules. I'll edit the commit message to be clearer.

Sep 24 2020, 1:28 PM · Restricted Project
void added a comment to D88195: Remove stale assert..

I'm super confused between the commit message and initial hunk, that seem to make sense and probably should go in clang-11 if it's not too late, and the additional tests for modules which the commit message does not address. Were these meant to be separate commits, because otherwise it looks like you uploaded unrelated stuff. Are C++20 modules broken with asm goto, or are you just adding additional test coverage for that?

Sep 24 2020, 1:01 PM · Restricted Project
void updated the diff for D88195: Remove stale assert..

Fix test.

Sep 24 2020, 12:59 PM · Restricted Project

Sep 23 2020

void added inline comments to D88195: Remove stale assert..
Sep 23 2020, 9:50 PM · Restricted Project
void updated the diff for D88195: Remove stale assert..

Fix test case.

Sep 23 2020, 9:50 PM · Restricted Project
void requested review of D88195: Remove stale assert..
Sep 23 2020, 7:10 PM · Restricted Project

Sep 17 2020

void added inline comments to D87865: PR47468: Fix findPHICopyInsertPoint, so that copies aren't incorrectly inserted after an INLINEASM_BR..
Sep 17 2020, 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