2014-09-24 11:05 GMT+04:00 Ilya Enkovich <enkovich....@gmail.com>:
> 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
I tried to generate PARALLEL with all regs set by call. Here is a
memset call I got:
(call_insn 23 22 24 2 (set (parallel [
(expr_list:REG_DEP_TRUE (reg:DI 0 ax)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:BND64 77 bnd0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:BND64 78 bnd1)
(const_int 0 [0]))
])
(call/j (mem:QI (symbol_ref:DI ("memset") [flags 0x41]
<function_decl 0x7ffff7f79400 memset.chkp>) [0 __builtin_memset S1
A8])
(const_int 0 [0])))
/export/users/ienkovic/mpx/tests/own-tests/255/test-255.c:11 652
{*call_value}
(expr_list:REG_RETURNED (reg/f:DI 100)
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:SI 4 si)
(expr_list:REG_DEAD (reg:DI 1 dx)
(expr_list:REG_UNUSED (reg:BND64 78 bnd1)
(expr_list:REG_UNUSED (reg:BND64 77 bnd0)
(expr_list:REG_UNUSED (reg:DI 0 ax)
(expr_list:REG_CALL_DECL
(symbol_ref:DI ("memset") [flags 0x41] <function_decl 0x7ffff7f79400
memset.chkp>)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))))))))))
(expr_list:DI (set (reg:DI 0 ax)
(reg:DI 5 di))
(expr_list:DI (use (reg:DI 5 di))
(expr_list:BND64 (use (reg:BND64 77 bnd0))
(expr_list:SI (use (reg:SI 4 si))
(expr_list:DI (use (reg:DI 1 dx))
(nil)))))))
During register allocation LRA generated a weird move instruction:
(insn 63 0 0 (set (reg/f:DI 100)
(parallel [
(expr_list:REG_DEP_TRUE (reg:DI 0 ax)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:BND64 77 bnd0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:BND64 78 bnd1)
(const_int 0 [0]))
])) -1
(nil))
Which caused ICE later in LRA. This move happens because of
REG_RETURNED (reg/f:DI 100) (see condition in inherit_in_ebb at
lra-constraints.c:5312). Thus this code in LRA doesn't accept
PARALLEL dest for calls.
So my question here is should I go through problems to enable PARALLEL
call destination or current sets are OK taking into account we would
still have multiple sets due to call_value_pop patterns?
Thanks,
Ilya
