On Mon, Jul 16, 2012 at 3:55 PM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>> On Fri, Jul 6, 2012 at 6:36 PM, Tom de Vries wrote:
>> > Bootstrapped and reg-tested (ada inclusive) on x86_64.
>> >
>> > OK for trunk?
>>
>> Ok.
>> Thanks,
>> Richard.
>>
>> > 2012-07-06 Tom de Vries
>> >
Richard Guenther wrote:
> On Fri, Jul 6, 2012 at 6:36 PM, Tom de Vries wrote:
> > Bootstrapped and reg-tested (ada inclusive) on x86_64.
> >
> > OK for trunk?
>
> Ok.
> Thanks,
> Richard.
>
> > 2012-07-06 Tom de Vries
> > Richard Guenther
> >
> > * tree-ssa-ccp.c (optimi
Tom de Vries wrote:
> 2012-07-06 Tom de Vries
> Richard Guenther
>
> * tree-ssa-ccp.c (optimize_unreachable): New function.
> (execute_fold_all_builtins): Use optimize_unreachable to optimize
> BUILT_IN_UNREACHABLE. Don't optimize after BUILT_IN_UNREACHABLE.
>
>
On Fri, Jul 6, 2012 at 6:36 PM, Tom de Vries wrote:
> On 06/07/12 13:01, Richard Guenther wrote:
>> On Thu, Jul 5, 2012 at 8:45 PM, Tom de Vries wrote:
>>> On 05/07/12 15:30, Michael Matz wrote:
Hi,
On Thu, 5 Jul 2012, Tom de Vries wrote:
> The asserts allow the return res
On 06/07/12 13:01, Richard Guenther wrote:
> On Thu, Jul 5, 2012 at 8:45 PM, Tom de Vries wrote:
>> On 05/07/12 15:30, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 5 Jul 2012, Tom de Vries wrote:
>>>
The asserts allow the return result to be optimized, but not the cfg
conditions.
>>>
On Thu, Jul 5, 2012 at 8:45 PM, Tom de Vries wrote:
> On 05/07/12 15:30, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 5 Jul 2012, Tom de Vries wrote:
>>
>>> The asserts allow the return result to be optimized, but not the cfg
>>> conditions.
>>>
>>> AFAIU, we can insert the asserts earlier. F.i., we c
On 05/07/12 15:30, Michael Matz wrote:
> Hi,
>
> On Thu, 5 Jul 2012, Tom de Vries wrote:
>
>> The asserts allow the return result to be optimized, but not the cfg
>> conditions.
>>
>> AFAIU, we can insert the asserts earlier. F.i., we can insert
>> aD.1711_6 = ASSERT_EXPR 0>
>> before the GIM
Hi,
On Thu, 5 Jul 2012, Tom de Vries wrote:
> The asserts allow the return result to be optimized, but not the cfg
> conditions.
>
> AFAIU, we can insert the asserts earlier. F.i., we can insert
> aD.1711_6 = ASSERT_EXPR 0>
> before the GIMPLE_COND in bb2.
Nope. That would require some mor
On Thu, Jul 5, 2012 at 2:49 PM, Tom de Vries wrote:
> On 04/07/12 19:02, Ulrich Weigand wrote:
>> Any suggestions how to fix this? Should tail merging detect
>> __builtin_unreachable and not merge such block? Or else, should
>> the CFG optimizer be extended (how?) to handle unreachable blocks
>>
Hi,
On Thu, 5 Jul 2012, Richard Guenther wrote:
> >> On Wed, Jul 4, 2012 at 7:02 PM, Ulrich Weigand
> >> wrote:
> >> > Any suggestions how to fix this? Should tail merging detect
> >> > __builtin_unreachable and not merge such block?
> >>
> >> That seems to be the most straight-forward thing
On 04/07/12 19:02, Ulrich Weigand wrote:
> Any suggestions how to fix this? Should tail merging detect
> __builtin_unreachable and not merge such block? Or else, should
> the CFG optimizer be extended (how?) to handle unreachable blocks
> with multiple predecessors better?
Ulrich,
I extended th
On Thu, Jul 5, 2012 at 2:44 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 4 Jul 2012, Steven Bosscher wrote:
>
>> On Wed, Jul 4, 2012 at 7:02 PM, Ulrich Weigand wrote:
>> > Any suggestions how to fix this? Should tail merging detect
>> > __builtin_unreachable and not merge such block?
>>
>> That see
Hi,
On Wed, 4 Jul 2012, Steven Bosscher wrote:
> On Wed, Jul 4, 2012 at 7:02 PM, Ulrich Weigand wrote:
> > Any suggestions how to fix this? Should tail merging detect
> > __builtin_unreachable and not merge such block?
>
> That seems to be the most straight-forward thing to do. I don't think
>
On Wed, Jul 4, 2012 at 7:02 PM, Ulrich Weigand wrote:
> Any suggestions how to fix this? Should tail merging detect
> __builtin_unreachable and not merge such block?
That seems to be the most straight-forward thing to do. I don't think
there are any other passes that do this kind of code merging
On Wed, Jul 4, 2012 at 10:02 AM, Ulrich Weigand wrote:
> Any suggestions how to fix this? Should tail merging detect
> __builtin_unreachable and not merge such block? Or else, should
> the CFG optimizer be extended (how?) to handle unreachable blocks
> with multiple predecessors better?
This bu
15 matches
Mail list logo