2014-09-23 22:01 GMT+04:00 Jeff Law <l...@redhat.com>: > On 09/23/14 00:31, Ilya Enkovich wrote: >> >> >> I did this change a couple of years ago and don't remember exactly >> what problem was caused by PARALLEL. But from my comment it seems >> parallel lead to values in BND0 and BND1 not to be actually defined by >> call from DF point of view. I'll try to reproduce a problem I had. > > Please do. That would indicate a bug in the DF infrastructure. I'm not > real familiar with the DF implementation, but a quick glance at > df_def_record_1 seems to indicate it's got support for a set destination > being a PARALLEL. > >>> This kind of scheme also doesn't tend to "play well" with exception >>> handling >>> & scheduling becuase you can't guarantee the sets and the call are in the >>> same block and scheduler as a single group. >> >> >> How can the sets and the call no be in the same block/group if all of >> them are parts of a single instruction? > > Obviously in the cases where we've had these problems in the past they were > distinct instructions. So EH interactions isn't going to be an issue for > MPX. > > However, we've still got the problem that the RTL you've generated is > ill-formed. If I understand things correctly, the assignments are the > result of the call, that should be modeled by having the destination be a > PARALLEL as mentioned earlier.
OK. Will try it. BTW call_value_pop patterns have two sets. One for returned value and one for stack register. How comes it differs much from what I do with bound regs? Thanks, Ilya > > > > Jeff
