Daniel Berlin wrote on 04/25/07 14:40:
> It still has the addresses_taken bitmap, remove it :)
Oh, right. Is it gone already?
> Also, I assume for a call with no return, it will be a GS_CALL with lhs ==
> NULL?
Yes. I clarified it. Thanks.
It still has the addresses_taken bitmap, remove it :)
Also, I assume for a call with no return, it will be a GS_CALL with lhs == NULL?
On 4/25/07, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
I have uploaded a new version of the tuples document, with the latest
discussions.
http://gcc.gnu.org/wi
Geert Bosch wrote on 04/25/07 11:49:
> I'd assume 100% contain 0 or more register operands.
> Did you mean 43% contain 1 or more?
Well, no. I meant 0 or more, but it's badly worded. It means that 43%
of the statements either have no operands or they contain only register
operands. I'll rephras
In 3.1, you write:
The statistics gathered over the programs mentioned in the
previous section show that about 43% of all statements contain 0 or
more
register operands
I'd assume 100% contain 0 or more register operands.
Did you mean 43% contain 1 or more?
-Geert
I have uploaded a new version of the tuples document, with the latest
discussions.
http://gcc.gnu.org/wiki/tuples
Aldy
On 4/15/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote on 04/14/07 22:59:
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's for
> statements that generate vdefs/vuses)
That's the thing. There c
Daniel Berlin wrote on 04/14/07 22:59:
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's for
> statements that generate vdefs/vuses)
That's the thing. There currently is *no* "aux" field to do this. We
may be for
> PRE is only using stmt_ann->uid as a convenient place to store the uid
> for local dominance for purposes of Load PRE.
> It's making up the UID on it's own :).
>
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's f
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 21:14:
> I just wondered if your document is documenting the final shape or what
> should be done during hte first transition. If the second, probably 2
> words should be accounted for location as source_locues i
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 16:14:
> Looks great, still I think "locus" and "block" could be both merged into
> single integer, like RTL land has INSN_LOCATOR.
That's the idea. But it's simpler to do this for now. The insn locator
is easi
> Jan Hubicka wrote on 04/14/07 21:14:
>
> > I just wondered if your document is documenting the final shape or what
> > should be done during hte first transition. If the second, probably 2
> > words should be accounted for location as source_locues is currently a
> > structure.
>
> The documen
Jan Hubicka wrote on 04/14/07 21:14:
> I just wondered if your document is documenting the final shape or what
> should be done during hte first transition. If the second, probably 2
> words should be accounted for location as source_locues is currently a
> structure.
The document is describing
> Jan Hubicka wrote on 04/14/07 16:14:
>
> > Looks great, still I think "locus" and "block" could be both merged into
> > single integer, like RTL land has INSN_LOCATOR.
>
> That's the idea. But it's simpler to do this for now. The insn locator
> is easily done at anytime during the implementat
Jan Hubicka wrote on 04/14/07 16:14:
> Looks great, still I think "locus" and "block" could be both merged into
> single integer, like RTL land has INSN_LOCATOR.
That's the idea. But it's simpler to do this for now. The insn locator
is easily done at anytime during the implementation.
> Also s
>
> I have added the design document and links to most of the discussions
> we've had so far. Aldy updated the document to reflect the latest thread.
>
> http://gcc.gnu.org/wiki/tuples
Looks great, still I think "locus" and "block" could be both merged into
single integer, like RTL land has INS
15 matches
Mail list logo
