>
> Yes. Although I'm streamlining things even more now. I've eliminated
> the "global" variables that store the excptr/filter, and instead each
> individual use location is asking for what it needs locally.
>
> Further, the actual landing pad itself is *not* generated in gimple.
> I had too ma
> On 08/10/2009 08:20 AM, Michael Matz wrote:
> >It's not that they _create_ side-effects, but they depend on some.
>
> Ah, fair enough. I hadn't actually thought that all through.
>
> >Btw, it's really wonderful that someone tackles EH-on-gimple ;-)
>
> I hadn't been planning on it, but my tra
On 08/13/2009 06:48 AM, Jan Hubicka wrote:
In gimple, the landing pad will be generated as
L.N:
exc_ptr.1 = EXC_PTR_EXPR (N);
filter.1 = FILTER_EXPR (N);
ie, copied into normal variables for use. These can be moved
about, or deleted, as the optimizer desires.
All of this seems much clea
Hi,
sorry for jumping in late, I had relatively urgent things to work at
and didn't had much time to think this over.
I am still having some problems understanding the plans on critical edge
splitting.
> EXC_PTR_EXPR and FILTER_EXPR will be expanded to take the EH
> region number as a parameter.
On 08/10/2009 08:20 AM, Michael Matz wrote:
It's not that they _create_ side-effects, but they depend on some.
Ah, fair enough. I hadn't actually thought that all through.
Btw, it's really wonderful that someone tackles EH-on-gimple ;-)
I hadn't been planning on it, but my trans-mem branch
Hi,
On Mon, 10 Aug 2009, Richard Henderson wrote:
> On 08/10/2009 05:53 AM, Michael Matz wrote:
> > Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be builtin
> > functions with proper attributes.
>
> Yes, that would be entirely possible. I thought about that later,
> after I'd p
On 08/10/2009 05:53 AM, Michael Matz wrote:
Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be builtin
functions with proper attributes.
Yes, that would be entirely possible. I thought about that later,
after I'd posted that message.
Yall worry about pure/const'ness downthread:
On Mon, Aug 10, 2009 at 3:21 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 10 Aug 2009, Richard Guenther wrote:
>
>> >> No and no. They will eventually resolve to pseudos generated during
>> >> rtl eh expansion. But to avoid silliness at the gimple level I don't
>> >> want to allow them to appear at
Hi,
On Mon, 10 Aug 2009, Richard Guenther wrote:
> >> No and no. They will eventually resolve to pseudos generated during
> >> rtl eh expansion. But to avoid silliness at the gimple level I don't
> >> want to allow them to appear at random.
> >
> > Shouldn't it be enough to have EXC_PTR_EXPR/
On Mon, Aug 10, 2009 at 2:53 PM, Michael Matz wrote:
> Hi,
>
> On Fri, 7 Aug 2009, Richard Henderson wrote:
>
>> On 08/07/2009 12:31 PM, Richard Guenther wrote:
>> > > L.N:
>> > > exc_ptr.1 = EXC_PTR_EXPR (N);
>> > > filter.1 = FILTER_EXPR (N);
>> >
>> > Does the above have
>> > virtual operand
Hi,
On Fri, 7 Aug 2009, Richard Henderson wrote:
> On 08/07/2009 12:31 PM, Richard Guenther wrote:
> > > L.N:
> > > exc_ptr.1 = EXC_PTR_EXPR (N);
> > > filter.1 = FILTER_EXPR (N);
> >
> > Does the above have
> > virtual operands, thus are there any aliases to whatever EXP_PTR_EXPR
> > or FILT
On 08/07/2009 12:31 PM, Richard Guenther wrote:
L.N:
exc_ptr.1 = EXC_PTR_EXPR (N);
filter.1 = FILTER_EXPR (N);
Will exc_ptr.1 and filter.1 be gimple registers?
Yes.
Does the above have
virtual operands, thus are there any aliases to whatever EXP_PTR_EXPR
or FILTER_EXPR load?
No and no
On Fri, Aug 7, 2009 at 9:22 PM, Richard Henderson wrote:
> On 08/06/2009 12:35 PM, Richard Henderson wrote:
>>
>> { exc_ptr, filter } = EH_LANDING_PAD;
>>
>> Placeholder for the landing-pad rtl. Has 2 outputs
>> for both the exception pointer and the filter.
>
> I'm going to drop th
On 08/06/2009 12:35 PM, Richard Henderson wrote:
{ exc_ptr, filter } = EH_LANDING_PAD;
Placeholder for the landing-pad rtl. Has 2 outputs
for both the exception pointer and the filter.
I'm going to drop this construct. Instead, I'm going to mark
the label, and have the land
On 08/06/2009 01:44 PM, Jan Hubicka wrote:
Hmm, EH_LANDING_PAD will still need to be somewhat special (as moving it
across eh edge or something will change behaviour) but it indeed seems
uite sane representation of fact that the EH/filter is really set by
runtime...
Yes, EH_LANDING_PAD is still
> New constructs:
>
> { exc_ptr, filter } = EH_LANDING_PAD;
>
> Placeholder for the landing-pad rtl. Has 2 outputs
> for both the exception pointer and the filter.
Hmm, EH_LANDING_PAD will still need to be somewhat special (as moving it
across eh edge or something will change beha
On Thu, Aug 6, 2009 at 15:35, Richard Henderson wrote:
>> I've also been thinking a good deal about a grand EH reorg; I'll try
>> to post something for you to comment on later today.
>
> Here ya go. Thoughts?
Y'all are going to make the LTO streamer cry.
I've also been thinking a good deal about a grand EH reorg; I'll try
to post something for you to comment on later today.
Here ya go. Thoughts?
r~
New constructs:
{ exc_ptr, filter } = EH_LANDING_PAD;
Placeholder for the landing-pad rtl. Has 2 outputs
for both the excepti
18 matches
Mail list logo
