Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-14 Thread Alexander Monakov
On Wed, 13 May 2015, Jan Hubicka wrote: > Thank you! This looks fine. Please add also the testcase that should break if > the new test was wrong andosmeone fixed postreload to allow use of the same > register > this check will prevent wrong code? I'm checking in a patch with the following addit

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-13 Thread Jan Hubicka
> On Mon, 11 May 2015, Jan Hubicka wrote: > > Yes, to make my original email clear, I think we are safe to remove > > peep2_reg_dead_p. > > > > I would however introduce a check that the call target is not also among > > parameters of the function. In this case the peephole would remove the load >

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-13 Thread Alexander Monakov
On Mon, 11 May 2015, Jan Hubicka wrote: > Yes, to make my original email clear, I think we are safe to remove > peep2_reg_dead_p. > > I would however introduce a check that the call target is not also among > parameters of the function. In this case the peephole would remove the load > and make th

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-11 Thread Jan Hubicka
> On 05/11/2015 01:46 PM, Uros Bizjak wrote: > >On Mon, May 11, 2015 at 8:00 PM, Jan Hubicka wrote: > >>>On Sun, 10 May 2015, Jan Hubicka wrote: > >>> > >On i386, peepholes that transform memory load and register-indirect jump > >into > >memory-indirect jump are overly restrictive in

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-11 Thread Jeff Law
On 05/11/2015 01:46 PM, Uros Bizjak wrote: On Mon, May 11, 2015 at 8:00 PM, Jan Hubicka wrote: On Sun, 10 May 2015, Jan Hubicka wrote: On i386, peepholes that transform memory load and register-indirect jump into memory-indirect jump are overly restrictive in that they don't allow combining w

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-11 Thread Uros Bizjak
On Mon, May 11, 2015 at 8:00 PM, Jan Hubicka wrote: >> On Sun, 10 May 2015, Jan Hubicka wrote: >> >> > > On i386, peepholes that transform memory load and register-indirect jump >> > > into >> > > memory-indirect jump are overly restrictive in that they don't allow >> > > combining >> > > when t

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-11 Thread Jan Hubicka
> On Sun, 10 May 2015, Jan Hubicka wrote: > > > > On i386, peepholes that transform memory load and register-indirect jump > > > into > > > memory-indirect jump are overly restrictive in that they don't allow > > > combining > > > when the jump target is loaded into %eax, and the called function

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-11 Thread Alexander Monakov
On Sun, 10 May 2015, Jan Hubicka wrote: > > On i386, peepholes that transform memory load and register-indirect jump > > into > > memory-indirect jump are overly restrictive in that they don't allow > > combining > > when the jump target is loaded into %eax, and the called function returns a > >

Re: [PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-10 Thread Jan Hubicka
> On i386, peepholes that transform memory load and register-indirect jump into > memory-indirect jump are overly restrictive in that they don't allow combining > when the jump target is loaded into %eax, and the called function returns a > value (also in %eax, so it's not dead after the call). Fi

[PATCH i386] Extend sibcall peepholes to allow source in %eax

2015-05-04 Thread Alexander Monakov
On i386, peepholes that transform memory load and register-indirect jump into memory-indirect jump are overly restrictive in that they don't allow combining when the jump target is loaded into %eax, and the called function returns a value (also in %eax, so it's not dead after the call). Fix this b