Message ID | mptimpyzmf1.fsf@arm.com |
---|---|
Headers | show |
Series | Support multiple ABIs in the same translation unit | expand |
On Wednesday, September 11, 2019, Richard Sandiford < richard.sandiford@arm.com> wrote:. > > > Sorry for the long write-up. > > Richard > *thanks* for the long write-up! Ciao! Steven
On Wed, 11 Sep 2019, 22:02:26 EEST Richard Sandiford wrote: > The reason for the PRU differences is that the port defines > targetm.hard_regno_call_part_clobbered, but uses it to test whether > a multi-register value contains a mixture of fully-clobbered and > fully-preserved registers. AFAICT the port doesn't actually have > individual registers that are partly clobbered, so it doesn't need > to define the hook. (I can see how the documentation gave a misleading > impression though. I've tried to improve it in one of the patches.) > The series moves away from testing hard_regno_call_part_clobbered > directly to testing cached information instead, and the way that the > cached information is calculated means that defining the hook the way > the PRU port does has no effect. In other words, after the series we > treat it (rightly IMO) as having a "normal" ABI whereas before we didn't. You are correct. Port does not have partially clobbered HW registers. And indeed I was worried about multi-register values. PRU testsuite showed no regression from trunk with your patch set. With your patch set, I tried to compare PRU assembly with and without defining the targetm.hard_regno_call_part_clobbered hook. There was much noise in compare-all-tests due to lto compiler ID strings, but after some filtering I think the output assembly was the same. Thanks, Dimitar
Dimitar Dimitrov <dimitar@dinux.eu> writes: > On Wed, 11 Sep 2019, 22:02:26 EEST Richard Sandiford wrote: >> The reason for the PRU differences is that the port defines >> targetm.hard_regno_call_part_clobbered, but uses it to test whether >> a multi-register value contains a mixture of fully-clobbered and >> fully-preserved registers. AFAICT the port doesn't actually have >> individual registers that are partly clobbered, so it doesn't need >> to define the hook. (I can see how the documentation gave a misleading >> impression though. I've tried to improve it in one of the patches.) >> The series moves away from testing hard_regno_call_part_clobbered >> directly to testing cached information instead, and the way that the >> cached information is calculated means that defining the hook the way >> the PRU port does has no effect. In other words, after the series we >> treat it (rightly IMO) as having a "normal" ABI whereas before we didn't. > You are correct. Port does not have partially clobbered HW registers. And > indeed I was worried about multi-register values. > > PRU testsuite showed no regression from trunk with your patch set. > > With your patch set, I tried to compare PRU assembly with and without defining > the targetm.hard_regno_call_part_clobbered hook. There was much noise in > compare-all-tests due to lto compiler ID strings, but after some filtering I > think the output assembly was the same. OK, great! Thanks for the testing. Richard