headers
Richard Henderson | 1 Feb 2007 01:58
Picon
Favicon

Re: [PATCH]: Expand finite() as inline i386 asm

On Thu, Jan 25, 2007 at 04:31:16PM +0100, Uros Bizjak wrote:
> Attached patch expands call to finite(), finitef() and finitel() as
> inline i386 asm (and produces the same code as is present in libm for
> those functions).

First, I'd rather any internals like optabs etc reference the 
C99 function isfinite, rather than the BSD name.

Second, as I mentioned in the notes for PR 30652, I suspect 
that using non-trapping comparisons will result in better
code than all these bit manipulations.  I.e.

  isfinite(d) => islessequal(fabs(d), DBL_MAX)

>        subl    $12, %esp
>        movl    $-1048577, %eax
>        flds    .LC0
>        faddl   16(%esp)
>        fstpl   (%esp)
>        movl    4(%esp), %edx
>        addl    $12, %esp
>        subl    %edx, %eax
>        xorl    %edx, %eax
>        shrl    $31, %eax
>        ret

        fldl    4(%esp)
        xorl    %eax, %eax
        fabs
        fldl    .LC0
(Continue reading)

Permalink | Reply | 6 comments |
headers
Richard Henderson | 1 Feb 2007 02:00
Picon
Favicon

Re: [PATCH]: Expand finite() as inline i386 asm

On Wed, Jan 31, 2007 at 04:58:32PM -0800, Richard Henderson wrote:
>   isfinite(d) => islessequal(fabs(d), DBL_MAX)

Oh, and I should note that this doesn't require *any* optabs,
since its completely generic.

r~
Permalink | Reply | 3 comments |
headers
Ian Lance Taylor | 1 Feb 2007 02:05
Picon
Favicon
Gravatar

PATCH COMMITTED: First lower-subreg patch

I am about to commit the first lower-subreg patch.  Where possible,
this splits double-wide values into separate single values.  This
permits the registers to be allocated separately, rather than forcing
them to be allocated as a pair.  This is controlled by a new option,
-fsplit-wide-types, which is turned on by default at -O1 and above.

This patch was originally written by Richard Henderson.  I rewrote it
somewhat.

This patch has some beneficial effects.  I have some followon patches
for better effect, by improving the register allocator to track when
different parts of a multi-register value are dead.

The patch has been bootstrapped and tested on i686-pc-linux-gnu,
sparc-sun-solaris2.10, and powerpc32-linux-gnu.  Thanks to Andrew
Pinski, Seongbae Park, and Alan Modra for testing.

Please let me know about any problems.

Ian


gcc/ChangeLog:
2007-01-31  Richard Henderson  <rth <at> redhat.com>
	    Ian Lance Taylor  <iant <at> google.com>

	* lower-subreg.c: New file.
	* rtl.def (CONCATN): Define.
	* passes.c (init_optimization_passes): Add pass_lower_subreg and
	pass_lower_subreg2.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Gerald Pfeifer | 1 Feb 2007 02:17

Re: [WWW] add "bug fix" to codingconventions.html

On Thu, 1 Feb 2007, Ben Elliston wrote:
> Thanks, Sandra.  Here's what I am committing, as I am assuming that
> Gerald had no objections to the change, in principle.

Thanks, and thanks Sandra and Joseph for your advice!

Ben, I assume you'll now go ahead and fix up our documentation and
web pages accordingly? :-P

Gerald
Permalink | Reply | 0 comments |
headers
Dorit Nuzman | 1 Feb 2007 02:57
Picon
Favicon

Re: [PATCH][RFC] Make the function vectorizer capable of doing type transformations

Richard Guenther <rguenther <at> suse.de> wrote on 31/01/2007 12:52:58:

...
>
> sure, I have a bunch of testcases that I did not include in the patch
yet.
>

cool

> > A few small questions/comments:
> >
> > > +
> > > +       nargs++;
> > > +       if (nargs >= 2)
> > > +    return false;
> > > +     }
> >
> > any inherent problem behind this check, or just restricting (FORNOW?)
to
> > the certain function-calls you expect to see? (which is fine, just
> > wondering)
>
> It's laziness - but also I don't expect vectorizable calls with more
> than 2 parameters (I'll add a comment clarifying that).
>

thanks

> Note that all the analysis stuff needs to go to vectorizable_function ()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dorit Nuzman | 1 Feb 2007 02:58
Picon
Favicon

Re: [PATCH][RFC] Make the function vectorizer capable of doing type transformations

I looked back at my "todo" notes and realized that there were a couple
additional bits that need fixing in vectorizable_call:

(1) I think we're going to ICE (need to find the testcase) in
vect_get_vec_def_for_copy, because we are deleting the scalar call stmt
that we are vectorizing,  while we are going to need it, at least when
ncopies>1, when we look for the vector-defs. I think the only reason we
haven't bumped into this ICE yet is because the sqrt is currently
vectorized as a "pattern_stmt" - in which case - we don't visit the scalar
sqrt to look for the vector def, but rather we visit the original stmt
(pow) - that is the stmt in the pattern that sqrt had replaced.  If sqrt
was generated not as a result of a pattern-recognition in the vectorizer -
we probably would have ICEd.  (I hope this is making any sense to you?).
Anyhow - the point is that we should probably be deleting the scalar calls
after we finished vectorizing all the stmts in the loop (just chain them
somewhere until then).

(2) We should also check that the return value of the function call is not
used after the loop (not "live") cause we simply don't handle that yet
(it's not difficult, but we simply don't do it yet). So all vectorizable_*
functions should check that.

I could take care of these next week (unless you get to it before then...)

dorit

> Thanks,
> Richard.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jerry DeLisle | 1 Feb 2007 03:32
Picon

Re: Disable use of -malign-double

Andrew Pinski wrote:
>> On Tue, Jan 30, 2007 at 11:17:23PM -0800, Andrew Pinski wrote:
>>> On Tue, 2007-01-30 at 23:11 -0800, Steve Kargl wrote:
>>>> The patch is self explanatory.
>>>>
>>>> 2007-01-31  Steven G. Kargl  <kargl <at> gcc.gnu.org>
>>>>
>>>> 	* options.c (gfc_post_options): Abort if -malign-double
>>>>
>>>>
>>>>
>>>> Index: options.c
>>>> ===================================================================
>>>> --- options.c	(revision 121271)
>>>> +++ options.c	(working copy)
>>>>  <at>  <at>  -294,6 +294,9  <at>  <at>  gfc_post_options (const char **pfilename
>>>>    if (gfc_option.flag_all_intrinsics)
>>>>      gfc_option.warn_nonstd_intrinsics = 0;
>>>>  
>>>> +  if (TARGET_ALIGN_DOUBLE)
>>>> +    fatal_error ("-malign-double is incompatible with libgfortran");
>>> This will not work.  As TARGET_ALIGN_DOUBLE is only defined for the x86
>>> backend.  Also it could default for some x86 targets.
>>>
>> How about this patch?
> 
> This is the wrong approach as some target might define -malign-double
> to mean something different from x86's definition.  Also I don't think
> we should be erroring out if someone compiles the whole libc, libgfortran,
> etc. with -malign-double which will work.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Feb 2007 03:46
Picon

Re: Disable use of -malign-double

On Wed, Jan 31, 2007 at 06:32:58PM -0800, Jerry DeLisle wrote:
> Andrew Pinski wrote:
> >>On Tue, Jan 30, 2007 at 11:17:23PM -0800, Andrew Pinski wrote:
> >>>On Tue, 2007-01-30 at 23:11 -0800, Steve Kargl wrote:
> >>>
> >>How about this patch?
> >
> >This is the wrong approach as some target might define -malign-double
> >to mean something different from x86's definition.  Also I don't think
> >we should be erroring out if someone compiles the whole libc, libgfortran,
> >etc. with -malign-double which will work.
> >

No other target uses -malign-double to means something else.  If 
another target did re-use this option to mean something else, then
that would be a bug.

> I would also suggest we had a blurb in the wiki to make it obvious and 
> provide an additional place to point people to every time the question pops 
> up, which it will continue to do until we get to some acceptable solution.

History shows that few people actually read documentation.
In fact, history shows that even when you tell people the
exact words in the documentation, they still ignore you.

--

-- 
Steve
Permalink | Reply | 0 comments |
headers
Andrew Pinski | 1 Feb 2007 03:59
Picon

Re: Disable use of -malign-double

> 
> On Wed, Jan 31, 2007 at 06:32:58PM -0800, Jerry DeLisle wrote:
> > Andrew Pinski wrote:
> > >>On Tue, Jan 30, 2007 at 11:17:23PM -0800, Andrew Pinski wrote:
> > >>>On Tue, 2007-01-30 at 23:11 -0800, Steve Kargl wrote:
> > >>>
> > >>How about this patch?
> > >
> > >This is the wrong approach as some target might define -malign-double
> > >to mean something different from x86's definition.  Also I don't think
> > >we should be erroring out if someone compiles the whole libc, libgfortran,
> > >etc. with -malign-double which will work.
> No other target uses -malign-double to means something else.  If 
> another target did re-use this option to mean something else, then
> that would be a bug.

Why?  This is a target specific option (it starts with -m).

> History shows that few people actually read documentation.
> In fact, history shows that even when you tell people the
> exact words in the documentation, they still ignore you.

So that is their problem, when stuff does not work and they
use an option which changes the ABI, then they get what they
deserve.  Really we should not have these options but for somereason in the
past, people thought it was a good idea to expose stuff like this.

You don't want to error out on all options that change the ABI in the
gfortran front-end.  If you want to error out for -malign-double, then error
out for the other options like -mabi=d64 and -mrtd and -mregparm= and -malign-natural
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph S. Myers | 1 Feb 2007 03:59

Re: Disable use of -malign-double

On Wed, 31 Jan 2007, Jerry DeLisle wrote:

> I think we should have a test at compile time to determine if the libraries
> have been aligned and if not issue an error if -malign-double is used. I am
> not sure exactly how we would do this, but maybe add a simple structure and
> test function in the library that is called at compile time to answer the
> question.

An established approach for checking ABI compatibility is to tag object 
files and libraries with ABI information and then have the linker complain 
if linking together objects with incompatible ABIs.  Sometimes there is a 
standard for the object file tags (e.g. in the ARM EABI), but if there 
isn't one for x86 you could establish a convention followed by GCC and GNU 
binutils for marking whether objects use align-double.

GCC may end up needing such conventions more generally for LTO in order to 
tell whether it can optimize across two objects compiled with different 
options.

--

-- 
Joseph S. Myers
joseph <at> codesourcery.com
Permalink | Reply | 0 comments |

Gmane