(if-conversion could directly generate masked load/stores
of course and not use a scratch-pad at all in that case).
[Abe wrote:]
IMO that`s a great idea, but I don`t know how to do it.
Hints would be welcome. In particular, how does one
>> "generate masked load/stores" at the GIMPLE level?
[Abe wrote:]
I believe Sebastian would agree that the new if converter is safer than the
old one
>> in terms of correctness at the time of running the code being compiled.
[...]
For now, we have a few performance regressions
[snip]
[Alan wrote:]
TBH my two cents would be that a performanc
On Tue, Jul 7, 2015 at 11:23 PM, Abe wrote:
>> (if-conversion could directly generate masked load/stores
>> of course and not use a scratch-pad at all in that case).
>
>
> IMO that`s a great idea, but I don`t know how to do it. Hints would be
> welcome. In particular, how does one "generate mas
Abe wrote:
I`m uncertain to what that is intended to refer, but I believe Sebastian would
agree that the new if converter is safer than the old one in terms of
correctness at the time of running the code being compiled.
>
even if they take us a step backwards from a performance standpoint.
(if-conversion could directly generate masked load/stores
of course and not use a scratch-pad at all in that case).
IMO that`s a great idea, but I don`t know how to do it. Hints would be welcome. In
particular, how does one "generate masked load/stores" at the GIMPLE level?
But are we cor
On 06/25/2015 03:43 AM, Richard Biener wrote:
Yes, and if you just look at scalar code then with the rewrite we can
enable store if-conversion unconditionally.
_But_
when the new scheme triggers vectorization cannot succeed on the
result as we get
if (cond)
*p = val;
if-converted to
Abe Skolnik wrote:
In tree-if-conv.c:[…]> if it doesn't trap, but has_non_addressable_refs, can't
we use
ifcvt_can_use_mask_load_store there too?
if an access could trap, but is addressable,> can't we use the scratchpad
technique
to get round the trapping problem?
That`s how we deal with loa
On 06/26/2015 08:57 AM, Richard Biener wrote:
Another possibility is to not share them and make sure to insert clobbers for
them when they become dead so later stack slot sharing can merge them again.
We've certainly had cases in the past where re-using a stack slot for an
object that has gone
On June 26, 2015 2:21:22 PM GMT+02:00, Alan Lawrence
wrote:
>Sebastian Pop wrote:
>> On Thu, Jun 25, 2015 at 4:43 AM, Richard Biener
>> wrote:
>>> when the new scheme triggers vectorization cannot succeed on the
>>> result as we get
>>>
>>> if (cond)
>>> *p = val;
>>>
>>> if-converted to
>
Sebastian Pop wrote:
On Thu, Jun 25, 2015 at 4:43 AM, Richard Biener
wrote:
when the new scheme triggers vectorization cannot succeed on the
result as we get
if (cond)
*p = val;
if-converted to
tem = cond ? p : &scratch;
*tem = val;
That's correct.
and
if (cond)
val =
On Thu, Jun 25, 2015 at 4:43 AM, Richard Biener
wrote:
> when the new scheme triggers vectorization cannot succeed on the
> result as we get
>
> if (cond)
> *p = val;
>
> if-converted to
>
> tem = cond ? p : &scratch;
> *tem = val;
That's correct.
>
> and
>
>if (cond)
> val =
On Wed, Jun 24, 2015 at 7:10 PM, Jeff Law wrote:
> On 06/22/2015 10:27 AM, Alan Lawrence wrote:
>
>>
>> My main thought concerns the direction we are travelling here. A major
>> reason why we do if-conversion is to enable vectorization. Is this is
>> targetted at gathering/scattering loads? Follow
On 06/22/2015 10:27 AM, Alan Lawrence wrote:
My main thought concerns the direction we are travelling here. A major
reason why we do if-conversion is to enable vectorization. Is this is
targetted at gathering/scattering loads? Following vectorization,
different elements of the vector being load
On 06/24/2015 10:50 AM, Ramana Radhakrishnan wrote:
On 12/06/15 21:50, Abe Skolnik wrote:
Hi everybody!
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they should have not been.
Some so
On 12/06/15 21:50, Abe Skolnik wrote:
Hi everybody!
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they should have not been.
Some source code could be rendered invalid due to null point
Abe Skolnik wrote:
Hi everybody!
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they should have not been.
Some source code could be rendered invalid due to null pointers
that were OK in
16 matches
Mail list logo
