Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On 2/9/18 10:51 AM, Segher Boessenkool wrote: >> +/* { dg-final { scan-assembler-times {\mvclzb\M} 2 } } */ >> +/* { dg-final { scan-assembler-times {\mvclzb\M} 2 } } */ This was a typo in the original test case I didn't notice. Looking closer, they meant one of these to be vclzd. I'll fix

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

Hi! On Thu, Feb 08, 2018 at 12:28:05PM -0600, Peter Bergner wrote: > On 2/8/18 10:38 AM, Peter Bergner wrote: > > * gcc.target/powerpc/builtins-1-be.c: Filter out gimple folding disabled > > message. Fix test for running in 32-bit mode. > > As we talked about offline, here's a bigger

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On 2/9/18 10:17 AM, Segher Boessenkool wrote: > On Thu, Feb 08, 2018 at 10:38:09AM -0600, Peter Bergner wrote: >> -/* { dg-final { scan-assembler-times "divd" 4 } } */ > >> +/* { dg-final { scan-assembler-times {\mdivd\M} 2 { target lp64 } } } */ > >> +/* { dg-final { scan-assembler-times {\mbl

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On Thu, Feb 08, 2018 at 10:38:09AM -0600, Peter Bergner wrote: > On 2/6/18 10:36 AM, Peter Bergner wrote: > > On 2/6/18 10:20 AM, David Edelsohn wrote: > >> Do the gen_XXXdi3 calls work if you use SDI iterator instead of GPR > >> iterator, as Segher suggested? > > > > Well it works _if_ we use

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On 2/8/18 10:38 AM, Peter Bergner wrote: > * gcc.target/powerpc/builtins-1-be.c: Filter out gimple folding disabled > message. Fix test for running in 32-bit mode. As we talked about offline, here's a bigger change to builtins-1-be.c that cleans up the test a little more, since we

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On 2/6/18 10:36 AM, Peter Bergner wrote: > On 2/6/18 10:20 AM, David Edelsohn wrote: >> Do the gen_XXXdi3 calls work if you use SDI iterator instead of GPR >> iterator, as Segher suggested? > > Well it works _if_ we use the first patch that changes the gen_* > patterns. If we go this route, I

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On 2/6/18 11:39 AM, Segher Boessenkool wrote: > Yes, if you make [u]divdi3 work for SDI (i.e. also for -m32) we'll never > have to special-case it again (also [u]moddi3?) Maybe, but there are no explicit calls to those, so I left them as is, since if we touch those, then we probably need to look

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On Tue, Feb 06, 2018 at 10:36:41AM -0600, Peter Bergner wrote: > On 2/6/18 10:20 AM, David Edelsohn wrote: > > Do the gen_XXXdi3 calls work if you use SDI iterator instead of GPR > > iterator, as Segher suggested? > > Well it works _if_ we use the first patch that changes the gen_* > patterns.

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On 2/6/18 10:20 AM, David Edelsohn wrote: > Do the gen_XXXdi3 calls work if you use SDI iterator instead of GPR > iterator, as Segher suggested? Well it works _if_ we use the first patch that changes the gen_* patterns. If we go this route, I agree we should use the SDI iterator instead of GPR.

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On Tue, Feb 6, 2018 at 10:43 AM, Peter Bergner wrote: > On 2/6/18 6:42 AM, Peter Bergner wrote: >> On 2/5/18 10:48 PM, David Edelsohn wrote: >>> On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote: I did also try calling expand_divmod() here which

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On 2/6/18 6:42 AM, Peter Bergner wrote: > On 2/5/18 10:48 PM, David Edelsohn wrote: >> On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote: >>> I did also try calling expand_divmod() here which did generate correct >>> code, the problem was that it wasn't as clean/optimized

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On Tue, Feb 06, 2018 at 06:42:06AM -0600, Peter Bergner wrote: > On 2/5/18 10:48 PM, David Edelsohn wrote: > > On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote: > >> I did also try calling expand_divmod() here which did generate correct > >> code, the problem was that it

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On 2/5/18 10:48 PM, David Edelsohn wrote: > On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote: >> I did also try calling expand_divmod() here which did generate correct >> code, the problem was that it wasn't as clean/optimized as the change >> to gen_divdi3. > > Why not

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote: > On 2/5/18 7:32 PM, David Edelsohn wrote: >> Peter, >> >> Why can't you place the tests into the final condition of the pattern >> so that the pattern fails and the normal GCC fallback machinery is >> used instead of

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

On 2/5/18 7:32 PM, David Edelsohn wrote: > Peter, > > Why can't you place the tests into the final condition of the pattern > so that the pattern fails and the normal GCC fallback machinery is > used instead of manually implementing the fallback emulation? You mean something like the following

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

Peter, Why can't you place the tests into the final condition of the pattern so that the pattern fails and the normal GCC fallback machinery is used instead of manually implementing the fallback emulation? The GPR iterator only defines DI for TARGET_POWERPC64, so how does GCC get into the muldi3

[PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

PR83926 shows a problem in expanding the _builtin_vsx_{div,udiv,mul}_2di builtins in 32-bit mode. The problem is that the splitters for the patterns explicitly call gen_{div,udiv,mul}di3 patterns, even in 32-bit mode and those patterns assume the associated 64-bit HW instructions exist when they