This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: implementation question


On Mon, May 5, 2014 at 8:57 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Mon, May 5, 2014 at 11:28 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 05/05/2014 08:47 AM, Richard Biener wrote:
>>> It really depends on how "3x" should materialize in the end.
>>> How do you triplicate ops with side-effects?  If you only
>>> triplicate ops without side-effects what is the sink that keeps
>>> the duplicated ops live?
>>
>> The vote, surely.  CSE would be absolutely determined to get rid of
>> all this redundant work.  I guess it'd all have to be done very late
>> or we'd need a new node that CSE can't see through.
>>
>> Would it be enough to mark all nodes that go into the vote as volatile?
>> I guess not: we wouldn't want to generate extra memory traffic.
>
> Well, it can end up using the exact same registers 3 times and spilling
> the result to the stack anyway.
>
> It has to be done before register allocation I suppose, and thus
> postreload-cse will come along ...

Thanks for all your feedback guys.

Based on our experiments, we noted too many exposure in the stack frames,
so it seems that a hardened ABI should be considered (with redundancy and
voting too).
All these facts lead to work on a specific RTL backend (e.g. hardened-x86,
hardened-ARM, etc.).

Any more comment will be greatly appreciated.

   Daniel.

>
> Richard.
>
>> Andrew.
>>



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD


San Lorenzo 47, 3rd Floor, Office 5

CÃrdoba, Argentina


Phone: +54 351 4217888 / +54 351 4218211

Skype: dgutson


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]