[PATCH] D92933: [ARM][MachineOutliner] Fix costs model.

Yvan Roux via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 17 05:16:57 PST 2020


yroux added inline comments.


================
Comment at: llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:5823
+      // outline this by saving all of its bytes.
+      else
+        NumBytesNoStackCalls += SequenceSize;
----------------
samparker wrote:
> yroux wrote:
> > samparker wrote:
> > > yroux wrote:
> > > > samparker wrote:
> > > > > yroux wrote:
> > > > > > samparker wrote:
> > > > > > > We were returning here previously, and now it's possible that there's a Candidate that hasn't been inserted into CandidatesWithoutStackFixups. When we update RepeatedSequences on line 5832, are we guaranteed to have not missed some candidates?
> > > > > > OK, in fact what I tried to do here is just to fix the costs given to the candidates which was wrongly set to Calldefault for all candidates when SP wasn't used and at least one of them was called with save/restore of LR into the stack.
> > > > > > 
> > > > > > We were returning here without outling these candidates, if the need of stack fixup was detected, but that wasn't necessary the instructions which migh need such a fixup were marked as illegal for outlining in the code lines 6055-6070
> > > > > > 
> > > > > > So, here we are just preparing the next step which will handle the fixups, it is the same logic which is used in the AArch64 implementation.
> > > > > > 
> > > > > > I'll renane and change the description of this revision
> > > > > Okay, thanks for reminding me how this plugs together. So I'm sorry if I'm being dense... but couldn't this still mean we could outline an instruction that is dependent upon one that isn't outlined? If we're iterating through a sequence of instructions, effectively copying them back into RepeatedSequenceLocs, what is stopping us from skipping over an instruction which a following instruction maybe dependent upon?
> > > > Problematic instructions (like predicated ones, PIC related ones, etc...) are marked as illegal inside getOutliningType function, then the MachineOutliner algorithm search the repeated patterns of legal instructions, thus RepatedSequenceLocs only contain Candidates composed by safe instructions and here we are just adding info about their kind and costs.  Hope it is clearer
> > > I don't think that alleviates my concerns... From what I understand the machine outliner will pass a sequence of instructions here that could be outlined, safely, together. My concern is the 'together' part. As I understand it, this change would allow an instruction in the sequence to not be placed in the sequence for outlining. I'd be more than happy to be pointed to a test to show that I'm talking non-sense :)
> > hmm sorry if I was confusing with my explanations, but here RepeatedSequenceLocs is a vector of Candidates, a Candidate is indeed a sequence of instructions which can be outlined together, but we don't remove instructions in that sequence.
> Yes, there's no removal here... but are all Candidates 'C' added into CandidatesWithoutStackFixups if line 5833 executes? Otherwise surely it is effectively removing a candidate. Looking again through this function, there are instructions being removed at 5742, so I now worried about that too.
right, we can remove a candidate if needed, it only means that instead of inserting a call to an outlined function three times we will only do two calls and don't touch the third occurence of the sequence if needed

Here ligne 5833 we only keep candidates whcih don't need a stack fixup (since we are not handling thjem yet) it means that if we have a sequence which sotre something on the stack, we wiull outline all the occurences which call that function without having to save/restore the link register into/from the stack.

At ligne 5742, we just remove the candidates where R12 and CPSR are lived accross them


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92933/new/

https://reviews.llvm.org/D92933



More information about the llvm-commits mailing list