Page MenuHomePhabricator

[X86][ISelLowering] refactor Varargs handling in X86ISelLowering.cpp

Authored by avl on Feb 18 2020, 2:07 PM.



This patch refactors handling of VarArgs in
That refactoring was requested while reviewing
D69372. Code related to varargs handling is removed
from X86TargetLowering::LowerFormalArguments and
is divided into smaller routines.

Diff Detail

Event Timeline

avl created this revision.Feb 18 2020, 2:07 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 18 2020, 2:07 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
avl updated this revision to Diff 248415.Mar 5 2020, 2:09 AM


Definitely a step in the right direction, thanks!


this struct and VarArgsLoweringHelper::getVarArgRegsDescriptor seem unnecessary and are only used in the is64Bit() part, can all the variables be inlined?

avl marked an inline comment as done.May 7 2020, 4:19 AM
avl added inline comments.

@aeubanks Thank you, for the comment and Excuse me for a delayed answer. I missed a notification about that comment. This structure is used as a parameter for createVarArgAreaAndStoreRegisters() and later I am going to use it in forwardMustTailParameters(for D69372). If it would be inlined then both of these functions - createVarArgAreaAndStoreRegisters and forwardMustTailParameters will have duplicated code. So the reason of VarArgsLoweringHelper::getVarArgRegsDescriptor is to have single register description and avoid code duplication.

Do you think it is still better to inline VarArgsLoweringHelper::getVarArgRegsDescriptor ?

aeubanks added inline comments.May 7 2020, 10:54 AM

But it looks like VarArgRegsDescr is only populated, and therefore only useful when is64Bit() is true. And the usage of RegDescr in createVarArgAreaAndStoreRegisters() seems to support that. Or do you mean you plan on extending getVarArgRegsDescriptor() later? Or using VarArgRegsDescr in non-64 bit contexts later?

avl marked an inline comment as done.May 7 2020, 1:21 PM
avl added inline comments.

I did not plan to use it in non-64 bit context(Though it could be done later if necessarily for some specific architecture). The idea was to create bits-neutral description(VarArgRegsDescr) once and use it later (in createVarArgAreaAndStoreRegisters and forwardMustTailParameters).

If that is unnecessary general for that case - then I would inline that descriptor.

avl updated this revision to Diff 263135.May 11 2020, 3:13 AM

addressed comments(inlined register descriptor).

Looks much better, just one small question.


This isn't the exact same logic as before, is that intended?

avl marked an inline comment as done.May 11 2020, 10:23 AM
avl added inline comments.

Yes. I moved it intentionally.
To make it clear if *FrameIndex is not set.
i.e., previously it was set in the very end under some conditions:

if (!Is64Bit) {
  // RegSaveFrameIndex is X86-64 only.
  if (CallConv == CallingConv::X86_FastCall ||
      CallConv == CallingConv::X86_ThisCall)
  // fastcc functions can't have varargs.

Instead, I always set FrameIndex to an invalid value in the start.
And update it if it really should be set.

Thus if we forget to set that value, we will immediately see 0xAAAAAAA index.

aeubanks accepted this revision.May 11 2020, 10:48 AM
aeubanks added a reviewer: aeubanks.

Ah 0xAAAAAAAA is supposed to be an invalid value, that's not immediately obvious. Maybe worth a comment?

This revision is now accepted and ready to land.May 11 2020, 10:48 AM
avl added a comment.May 12 2020, 5:29 AM

Thank you! Would add comment before integrating.

This revision was automatically updated to reflect the committed changes.