[PATCH] D18541: [CodeGen] Consider register modified if it's used to pass landing pad parameters.

[Marcin Kościelnicki via llvm-commits]

koriakin added a comment.

In http://reviews.llvm.org/D18541#419458, @MatzeB wrote:

> > This was no accident, I very carefully arranged to represent these masks as something other than MachineOperands specifically so that PEI *wouldn't* consider them clobbered. :)
>
> > 
>
> > On Win64, the unwinder arranges to restore all your registers to what they were at the point of the throwing call site, either after you rejoin normal control flow (via catchret in LLVM) or by unwinding out of the frame. They *don't* restore the registers on entry into a funclet cleanuppad or catchpad, which is why we have these register masks in in the first place. Win64 has *many* CSRs including XMM registers, so if things were not arranged this way, all functions using WinEH would have ridiculously large prologues.
>
>
> While in principle this is rather a problem for shrink wrapping and not announcing the clobber to MRI::addPhysRegsUsedMask() is wrong. I can see that in practice we are simply not there yet.
>
> So it seems to me like the best action today would be to leave the decision of what registers modified by the personality function should be saved/restored to the target in TargetFrameLowering::determineCalleeSaves(), and maybe provide a shared implementation of this bit to avoid code duplication...


Well, my first diff was like that (I forgot to add context, but the implementation is indeed in SystemZTargetFrameLowering::determineCalleeSaves()), so I'm fine with that.

But, how about keeping this target-independent, and making it depend on personality function kind instead?  AFAICS the underlying issue also affects x86_64-linux with coldcc - do we want to support this?


Repository:
  rL LLVM

http://reviews.llvm.org/D18541