On 02/18/2016 02:56 AM, Richard Biener wrote:
On Wed, Feb 17, 2016 at 5:10 PM, Jeff Law wrote:
On 02/17/2016 07:13 AM, Richard Biener wrote:
- /* Continue walking until we reach a kill. */
- while (!stmt_kills_ref_p (temp, ref));
+ /* Continue walking until we reach a full kill as a singl
On Mon, Feb 22, 2016 at 5:32 PM, Jeff Law wrote:
> On 02/22/2016 07:32 AM, Richard Biener wrote:
>
>>> Presumably DOM is not looking at r = s.r and realizing it could look s.r
>>> piece-wise in the available expression table. If it did, it would
>>> effectively turn that fragment into:
>>>
>>>
On 02/22/2016 07:32 AM, Richard Biener wrote:
Presumably DOM is not looking at r = s.r and realizing it could look s.r
piece-wise in the available expression table. If it did, it would
effectively turn that fragment into:
s = { {1, 2}, 3 };
s.r.x = 1;
s.r.y = 2;
struct R r
On Fri, Feb 19, 2016 at 10:01 PM, Jeff Law wrote:
> On 02/18/2016 02:56 AM, Richard Biener wrote:
Just a short quick comment - the above means you only handle partial
stores
with no interveaning uses. You don't handle, say
struct S { struct R { int x; int y; } r; int
On 02/18/2016 02:56 AM, Richard Biener wrote:
Just a short quick comment - the above means you only handle partial
stores
with no interveaning uses. You don't handle, say
struct S { struct R { int x; int y; } r; int z; } s;
s = { {1, 2}, 3 };
s.r.x = 1;
s.r.y = 2;
struct R r = s.r;
On 02/18/2016 02:56 AM, Richard Biener wrote:
Right. But handling that has never been part of DSE's design goals. Once
there's a use, DSE has always given up.
Yeah, which is why I in the end said we need a "better" DSE ...
Well, I don't see a rewrite/redesign in the mid-term horizon.
Ha
On Wed, Feb 17, 2016 at 5:10 PM, Jeff Law wrote:
> On 02/17/2016 07:13 AM, Richard Biener wrote:
>>>
>>> - /* Continue walking until we reach a kill. */
>>> - while (!stmt_kills_ref_p (temp, ref));
>>> + /* Continue walking until we reach a full kill as a single statement
>>> + or there ar
On 02/17/2016 07:13 AM, Richard Biener wrote:
- /* Continue walking until we reach a kill. */
- while (!stmt_kills_ref_p (temp, ref));
+ /* Continue walking until we reach a full kill as a single statement
+ or there are no more live bytes. */
+ while (!stmt_kills_ref_p (temp, ref)
+
On Wed, Feb 17, 2016 at 3:02 PM, Jeff Law wrote:
> On 02/17/2016 03:48 AM, Richard Biener wrote:
>
>>> I instrumented a bootstrap -- the improved DSE finds ~20k additional DSE
>>> opportunities during a GCC bootstrap that could not be found by the
>>> current
>>> DSE. Yes, 20k additional statemen
On 02/17/2016 03:48 AM, Richard Biener wrote:
I instrumented a bootstrap -- the improved DSE finds ~20k additional DSE
opportunities during a GCC bootstrap that could not be found by the current
DSE. Yes, 20k additional statements deleted by tree DSE. Yow!
Well, DCE also can do quite some DS
On Wed, Feb 17, 2016 at 8:30 AM, Jeff Law wrote:
> On 02/14/2016 11:38 AM, Richard Biener wrote:
>>
>> On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law
>> wrote:
>>>
>>> On 02/12/2016 10:21 AM, Jeff Law wrote:
>
> But really we simply need a better DSE algorithm.
So the way t
On 02/14/2016 11:38 AM, Richard Biener wrote:
On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law wrote:
On 02/12/2016 10:21 AM, Jeff Law wrote:
But really we simply need a better DSE algorithm.
So the way to fix DSE is to keep the existing algorithm and track the
hunks of Complex/aggregates
On 02/14/2016 11:38 AM, Richard Biener wrote:
On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law wrote:
On 02/12/2016 10:21 AM, Jeff Law wrote:
But really we simply need a better DSE algorithm.
So the way to fix DSE is to keep the existing algorithm and track the
hunks of Complex/aggregates
On 02/14/2016 11:38 AM, Richard Biener wrote:
On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law
wrote:
On 02/12/2016 10:21 AM, Jeff Law wrote:
But really we simply need a better DSE algorithm.
So the way to fix DSE is to keep the existing algorithm and track
the hunks of Complex/aggregates
On February 14, 2016 5:35:13 PM GMT+01:00, Jeff Law wrote:
>On 02/12/2016 10:21 AM, Jeff Law wrote:
>>> But really we simply need a better DSE algorithm.
>> So the way to fix DSE is to keep the existing algorithm and track the
>> hunks of Complex/aggregates that have been set a second time.
>>
>>
On 02/12/2016 10:21 AM, Jeff Law wrote:
But really we simply need a better DSE algorithm.
So the way to fix DSE is to keep the existing algorithm and track the
hunks of Complex/aggregates that have been set a second time.
My first thought was to implement this as an inverted bitmap. ie, set
it
On 02/12/2016 02:04 AM, Richard Biener wrote:
So what am I missing here? Is there any kind of aliasing issues I need to
be aware of? Any other dragons lurking?
I think what you are missing is that you'll "optimize"
_Complex double x, y;
void foo (void)
{
x = y;
}
then but dependent on
On Fri, Feb 12, 2016 at 12:53 AM, Jeff Law wrote:
>
> So I've never thought much about our Complex support and I don't have a lot
> of confidence in the coverage for our testsuite for these changes. So I'd
> really appreciate someone with more experience thinking about this issue for
> a bit.
>
>
18 matches
Mail list logo
