Re: [RFC] sparse SSA construction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 6, 2017 at 7:44 PM, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>>
>> May I ask the question that, the SSA form you are building
>> from this codes. Does it violate the SSA dominance property
>
> Of course not. Unless there is a bug, that is.

I am very glad to heard that :-)

>
>> In other word, does it produce the "usage before
>> define" IR similar to this?
>>
>>         and.32      %r3 <- %r4, $-65
>>          or.32       %r4 <- %r3, $64
>
> It gives the code as I showed as reply to Dibyendu's mail.
> For example, his code gives:
>         foo:
>         .L0:
>                 <entry-point>
>                 and.32      %r2 <- UNDEF, $-65
>                 or.32       %r3 <- %r2, $64
>                 lsr.32      %r4 <- %r3, $6
>                 cast.1      %r5 <- (32) %r4
>                 cast.32     %r6 <- (1) %r5
>                 setne.32    %r7 <- %r6, $1
>                 ret.32      %r7
>
> with UNDEF being a new type of pseudo.

OK. So far so good.

>
> On purpose, nothing is done yet with the UNDEFs.
>
>> That I am very curios how it was done. See the above
>> question.
>
> IMO, the best is to read the article. My code is
> still very close to the article's pseudo-code.
>
> Basically, it's a lazy approach. Things are done
> when possible and are delayed if not.

So you are building the SSA for the memory variable
I assume?

Directly from the linearize process?

> More specifically, you can do what is needed in a BB
> once you have all the parents, otherwise you need to
> delay things. The article call this 'BB is sealed'
> and there is a 'seal' operation that need to be called
> to process what was delayed.
> Complications arise with gotos (and the article doesn't
> talk about them) but I've added a solution for it
> (but I would like to return to it later).

I am missing the obvious. Where is this article?

>
> From what I've seen/heard this algo have been pretty well
> received. Personnaly, I'm very happy with its simplicity
> and its result.

Great!

>
> One thing that is missing is the more complex cases
> with trivial phi-nodes.

Can you clarify?

>
> Another thing I would like to change is the ptrmap
> implementation I've added: it need to be hash-table based
> (but it's only an implementation detail that matters
> for performance on really big functions).

Which ptrmap? The one used for CSE?

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux