On Tue, Oct 2, 2012 at 12:08 PM, Vladimir Yakovlev wrote:
> Will we wait for LRA commit or is it possiple to commit to trank
> vzeroupper patch now?
Since we can emit vzeroupper now, we will wait for LRA.
Uros.
Will we wait for LRA commit or is it possiple to commit to trank
vzeroupper patch now?
2012/10/2 Uros Bizjak :
> On Tue, Oct 2, 2012 at 11:35 AM, Vladimir Yakovlev
> wrote:
> The compiler with the patch and without post_reload.patch is built and
> works
> successfully. It has the on
On Tue, Oct 2, 2012 at 11:35 AM, Vladimir Yakovlev wrote:
The compiler with the patch and without post_reload.patch is built and
works
successfully. It has the only failure with avx-vzeroupper-3 test because of
post reload problem.
>>>
>>> Ok, can you please elaborate a bit on
2012/9/30 Uros Bizjak :
> On Thu, Sep 20, 2012 at 8:35 AM, Uros Bizjak wrote:
>> On Thu, Sep 20, 2012 at 8:06 AM, Vladimir Yakovlev
>> wrote:
>>> The compiler with the patch and without post_reload.patch is built and works
>>> successfully. It has the only failure with avx-vzeroupper-3 test beca
On Thu, Sep 20, 2012 at 8:35 AM, Uros Bizjak wrote:
> On Thu, Sep 20, 2012 at 8:06 AM, Vladimir Yakovlev
> wrote:
>> The compiler with the patch and without post_reload.patch is built and works
>> successfully. It has the only failure with avx-vzeroupper-3 test because of
>> post reload problem.
On Thu, Sep 20, 2012 at 8:06 AM, Vladimir Yakovlev wrote:
> The compiler with the patch and without post_reload.patch is built and works
> successfully. It has the only failure with avx-vzeroupper-3 test because of
> post reload problem.
Ok, can you please elaborate a bit on this filure? Perhaps
On Tue, Sep 18, 2012 at 10:57 PM, Vladimir Yakovlev
wrote:
> Attached files
> i386.patch contains changes for vzeroupper placement.
> post_reload.patch contens changes for post reload pass.
>
> I have bootstrap problem with post_reload.patch.
Does the patch without post_reload.patch work as expec
On Tue, Sep 18, 2012 at 2:18 PM, Vladimir Yakovlev wrote:
> I tried to perform vzeroupper emitting after reload as additional pass
> of mode switching.
> I sow one problem that I don't know haw to overcome. After
> 'pro_and_epilogue', there can be no
> flow edge to exit block and pre_exit block is
I tried to perform vzeroupper emitting after reload as additional pass
of mode switching.
I sow one problem that I don't know haw to overcome. After
'pro_and_epilogue', there can be no
flow edge to exit block and pre_exit block is not created in this case
(see rotine create_pre_exit).
Without that
Hello!
> You are right I no need the changes in mode-switchig.c at all. After I
> remove additional argument from EMIT_MODE_SET and run 'make check' I
> found no differences with make check result of previous run. So I no
> need in any changes in the middle end part.
Vladimir, can you please inv
Hi Ricard,
You are right I no need the changes in mode-switchig.c at all. After I
remove additional argument from EMIT_MODE_SET and run 'make check' I
found no differences with make check result of previous run. So I no
need in any changes in the middle end part.
Regards,
Vladimir
P.S. I'll be
> Looks OK to me, though I have no authority to approve it
> except SH specific part.
Is there any more comments? Can it be committed in trank?
Regards,
Vladimir
2012/9/14 Kaz Kojima :
> Vladimir Yakovlev wrote:
>> I reproduced the failure and found reason of it. I understood haw it
>> resolve
Vladimir Yakovlev writes:
> I reproduced the failure and found reason of it. I understood haw it
> resolve and now I need small changes only - additional argument of
> EMIT_MODE_SET. Is it good fo trunk?
I'm not sure I understand why you need to know the instruction.
The x86 code was:
+ if
Vladimir Yakovlev wrote:
> I reproduced the failure and found reason of it. I understood haw it
> resolve and now I need small changes only - additional argument of
> EMIT_MODE_SET. Is it good fo trunk?
>
> Thank you,
> Vladimir
>
> 2012-09-14 Vladimir Yakovlev
>
> * (optimize_mode_s
Additionaly.
You can find the patch history in
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01590.html.
I need this changes for my implementation of vzeroupper placement:
for some statements I have no needs doing real insertion.
I tested the changes on bootstrap using config
../gcc/configu
Hello,
I reproduced the failure and found reason of it. I understood haw it
resolve and now I need small changes only - additional argument of
EMIT_MODE_SET. Is it good fo trunk?
Thank you,
Vladimir
2012-09-14 Vladimir Yakovlev
* (optimize_mode_switching): Added an argument EMIT_MODE
Thank you for testing.
> With commenting out "if (i != mode)" of the hunk
I changed type of transp and added this checking because if we reset
transp[mode], then later in the loop
FOR_EACH_BB (bb)
sbitmap_not (kill[bb->index], transp[i][bb->index]);
we set kill of the bb for that
> I've tried the patch on sh4-unknown-linux-gnu. I see new failures
> with it:
Here is a reduced test case for sh4-unknown-linux-gnu.
volatile double gd[32];
volatile float gf[32];
int main ()
{
int i;
for (i = 0; i < 32; i++)
gd[i] = i * 4, gf[i] = i;
for (i = 0; i < 32; i++)
i
Vladimir Yakovlev wrote:
> I discoverd some inaccuracies when tried to implement vzeroupper
> insertion (pr#47440).
>
> First, I made 'transp' as an array of bit vectors rather bitvector
> because it should be own for each mode, otherwise its resetting on
> mode changing kills all modes (and new
I discoverd some inaccuracies when tried to implement vzeroupper
insertion (pr#47440).
First, I made 'transp' as an array of bit vectors rather bitvector
because it should be own for each mode, otherwise its resetting on
mode changing kills all modes (and new mode also).
Another changes concern
20 matches
Mail list logo
