Re: Proposed doc update for Explicit Reg Vars 2/3

2015-10-21 Thread Segher Boessenkool
On Tue, Oct 20, 2015 at 09:24:48PM -0700, David Wohlferd wrote:
> >>+Registers can be a limited resource on some systems and allowing the
> >They are a limited resource on almost all systems.  "Scarce resource"?
> 
> "Scarce" it is.  I've left the rest alone for the moment, but how would 
> you feel about:
> 
> "Registers are a scarce resource on most systems and allowing the"

That sounds fine.

> >>+All global register variable declarations must precede all function
> >>+definitions.  If such a declaration appears after function definitions,
> >>+the declaration would be too late to prevent the register from being used
> >>+for other purposes in the preceding functions.
> >This isn't true anymore, not even with -fno-toplevel-reorder or -O0.
> 
> I'm going to interpret this as a recommendation to remove this text, 
> rather than just an FYI.  Done.

Perfect.

> >>+When selecting a register, choose one that is normally saved and
> >>+restored by function calls on your machine.  This ensures that code
> >>+which is unaware of this reservation (such as library routines) will
> >>+restore it before returning.
> >The compiler also warns, possibly for the unlikely case that the user has
> >not read the documentation.
> 
> I'm going to interpret this comment as just an FYI, and NOT something 
> that should be added to the docs.

That is fine of course.

Cheers,


Segher


Re: Prototype implementation: Improving effectiveness and generality of auto-vectorization

2015-10-21 Thread Richard Biener
On Thu, Oct 15, 2015 at 12:20 PM, sameera  wrote:
> Hi Richard,
>
> This is with reference to our discussion at GNU Tools Cauldron 2015
> regarding my talk titled "Improving the effectiveness and generality of GCC
> auto-vectorization." We, at Imaginations Technologies, have further worked
> on finalizing the algorithms for transformations to achieve efficient
> target-aware reordering instruction selection. We have implemented the
> prototype in python to demonstrate the capabilities of the algorithm and
> verify the claims made in the presentation.
>
> I am attaching the prototype along with the documented algorithm for review
> purposes. We would be starting with design and implementation of the same in
> GCC and would be glad to receive comments, feedback and suggestions.

So I finally sat down and skimmed over auto_vectorization.txt.  The first thing
I notice is that you constrain your input language to sth you define yourself.
In the end you will need to work on GIMPLE in SSA form.  Thus the
Algorithm as described needs to construct its AST from that GIMPLE
representation.
Loop count and data reference analysis is provided by GCC and you need to work
with the way their result is presented.

As with the presentation the paper is mostly about optimizing the interleaving
code.  That's fine in principle but I suspect that the AST needs to get explicit
support for "vectorized stmts" that perform type conversions (like type
conversions themselves or widening operations), that is, represent the fact
that for certain loops you need N vectorized stmts for stmt A and M vectorized
stmts for stmt B.  This is an important observation once you get to the point
supporting targets with multiple vector sizes (and instructions like the x86_64
integer - double conversions which go from 128bit to 256bit vectors).

I somewhat miss an idea on how to deal with irregular SLP cases - that is,
does the AST model each (current) SLP node as a single statement or
does it model individual vector elements (so you can insert no-op compensation
code to make the operations match).  Consider

 a[i] = b[i] * 3;
 a[i+1] = b[i+1];

which can be vectorized with SLP if you realize you can multiply b[i+1] by 1.

As of implementing the whole thing in GCC I recently spent some more time
thinking and came to the conclusion that the path to the fastest improvements
in GCC code-gen would be to build the new AST after the current analysis
phase finished, do the optimization and drive code-generation off the new AST.
Thus keep things like data-ref and dependence analysis as is, as well as
group analysis and SLP tree construction.  Build the AST from the vectorizer
"IL" at the point vect_transform_loop / vect_slp_transform_bb is called.

More and more of the rest of the vectorizer code can then be "slowly" moved
to work on the AST and AST construction be moved earlier.

Richard.

>
> - Thanks and regards,
>   Sameera Deshpande


Re: Proposed doc update for Explicit Reg Vars 1/3

2015-10-21 Thread Segher Boessenkool
On Tue, Oct 20, 2015 at 09:14:51PM -0700, David Wohlferd wrote:
> >Abot the patches themselves...  Hard to review again, sigh...
> 
> I know, and I'm sorry.
> 
> I just can't see any way to completely re-org the text without the patch 
> becoming a nightmare.  I was hoping the html links would make that 
> easier, but I guess not.  On the plus side, Explicit reg vars is the 
> last section I plan to do this to.  I appreciate you taking the time.

The HTML links did help; it still is hard to review.

> >It provides an introduction, which is quite helpful in this case.  Without
> >some blurb the two-entry menu looks silly too.
> >
> >Can you move the intro to the separate pages instead of losing it 
> >altogether?
> 
> I did keep a small amount of intro on the the menu page.  If you feel 
> there's more that we should keep, I'm certainly willing to re-visit 
> this.  Perhaps after we resolve the local/global stuff so we know what 
> we really want to say.

Well, the intro as it was was a nice condensed description of the two kinds
of reg var.  If you don't want that in the menu, it would be nice to start
the separate pages with it (so that the first paragraph says at a glance
what the section is about).

> >Two spaces after a full stop
> 
> Oops.Again.You can probably just automatically add this 
> to every review you send me.  It's just so automatic for me to type this 
> way.

And only one after a comma, that was new ;-)

> In my (feeble) defense, the original text had this too.

Good excuse ;-)

> Lastly, if some external website is linking to "Explicit Reg Vars", what 
> do we want to have happen now that we have renamed that to "Explicit 
> Register Variables"?  Should the link just fail?

I think so yes.  Unless perhaps we *know* certain pages (maybe our own)
link to certain places.


Segher


Re: TARGET_PROMOTE_PROTOTYPES question

2015-10-21 Thread Jeff Law

On 10/20/2015 02:26 PM, Steve Ellcey  wrote:

I have a question about the TARGET_PROMOTE_PROTOTYPES macro.  This macro
says that types like short or char should be promoted to ints when
passed as arguments, even if there is a prototype for the argument.

Now when I look at the code generated on MIPS or x86 it looks like there
is conversion code in both the caller and the callee.  For example:

int foo(char a, short b) { return a+b; }
int bar (int a) { return foo(a,a); }


In the rtl expand dump (on MIPS) I see this in bar:

(insn 6 3 7 2 (set (reg:SI 200)
 (sign_extend:SI (subreg:HI (reg/v:SI 199 [ a ]) 2))) x.c:2 -1
  (nil))
(insn 7 6 8 2 (set (reg:SI 201)
 (sign_extend:SI (subreg:QI (reg/v:SI 199 [ a ]) 3))) x.c:2 -1
  (nil))

Which insures that we pass the arguments as ints.
And in foo we have:

(insn 8 9 10 2 (set (reg/v:SI 197 [ a+-3 ])
 (sign_extend:SI (subreg:QI (reg:SI 198) 3))) x.c:1 -1
  (nil))
(insn 10 8 11 2 (set (reg/v:SI 199 [ b+-2 ])
 (sign_extend:SI (subreg:HI (reg:SI 200) 2))) x.c:1 -1
  (nil))

Which makes sure we do a truncate/extend before using the values.

Now I know that we can't get rid of these truncation/extensions
entirely, but do we need both?  It seems like foo could say that
if the original registers (198 and 200) are argument registers
that were extended to SImode due to TARGET_PROMOTE_PROTOTYPES
then we don't need to do the truncation/extension in the callee
and could just use the SImode values directly.  Am I missing
something?  Or are we doing both just to have belts and suspenders
and want to keep it that way?
From reading the docs for TARGET_PROMOTE_PROTYPES, it would seem like 
it's the caller's responsibility.


However, it's not clear from the docs if it's something the callee can 
rely on, particularly when interoperating with a non-GCC compiler.


Does the ABI say anything about sub-word argument handling on the caller 
or callee side?


jeff


Re: TARGET_PROMOTE_PROTOTYPES question

2015-10-21 Thread Eric Botcazou
> I have a question about the TARGET_PROMOTE_PROTOTYPES macro.  This macro
> says that types like short or char should be promoted to ints when
> passed as arguments, even if there is a prototype for the argument.
> 
> Now when I look at the code generated on MIPS or x86 it looks like there
> is conversion code in both the caller and the callee.

We used to to the same on SPARC 32-bit, see PR target/46208.

-- 
Eric Botcazou


Re: Proposed doc update for Explicit Reg Vars 2/3

2015-10-21 Thread Jeff Law

On 10/21/2015 05:27 AM, Segher Boessenkool wrote:

On Tue, Oct 20, 2015 at 09:24:48PM -0700, David Wohlferd wrote:

+Registers can be a limited resource on some systems and allowing the

They are a limited resource on almost all systems.  "Scarce resource"?


"Scarce" it is.  I've left the rest alone for the moment, but how would
you feel about:

"Registers are a scarce resource on most systems and allowing the"


That sounds fine.
I installed this patch from David with an update to use the "Registers 
are a scarce resource ..." text.


Thanks David & Segher.

jeff



UTF-8 quotation marks in diagnostics

2015-10-21 Thread D. Hugh Redelmeier
Several of us don't want UTF-8 quotation marks in diagnostics in our 
environment (Jove subshells).  We'd like a way to turn them off.  We don't 
think that they are a bad idea but they are bad in our environment.



English-language diagnostic messages will now use Unicode
quotation marks in UTF-8 locales. (Non-English messages
already used the quotes appropriate for the language in
previous releases.) If your terminal does not support UTF-8
but you are using a UTF-8 locale (such locales are the default
on many GNU/Linux systems) then you should set LC_CTYPE=C in
the environment to disable that locale. Programs that parse
diagnostics and expect plain ASCII English-language messages
should set LC_ALL=C. See Markus Kuhn's explanation of Unicode
quotation marks for more information.

This suggests that LC_CTYPE=C would do what we want: go back to ` and
' instead of 342\200\230 and \342\200\231.

I find that a little confusing and scary.  I would expect that setting
LC_CTYPE=C would have the affect of changing the lexing done by the C
compiler.  For one thing, valid characters in strings would be
different.  This we don't want.

gcc(1) says:

The LC_CTYPE environment variable specifies character
classification.  GCC uses it to determine the character
boundaries in a string; this is needed for some multibyte
encodings that contain quote and escape characters that are
otherwise interpreted as a string end or escape.

The LC_MESSAGES environment variable specifies the language to
use in diagnostic messages.


An experiment on my Fedora 20 system shows:

- LANG=en_CA.UTF-8 [correct]

- LC_CTYPE isn't set by default

- setting LC_CTYPE to C gets rid of the UTF-8 quotes in GCC diagnostics.
  That's surprising because the manpage doesn't say that it affects diagnostics.

- setting LC_MESSAGES to C DOES NOT get rid of the UTF-8 quotes in GCC 
diagnostics
  That's surprising because the manpage does say that it affects diagnostics.
  I hope that it only affect compile-time diagnostics.

That sure sounds like we should NOT set LC_CTYPE=C because of bad
side-effects: it changes how the program is lexed.  And the
documentation gives no basis for thinking that it would suppress those
UTF-8 quotes in messages (even though testing shows that this works).

That sure sounds like we should set LC_MESSAGES=C, but that doesn't work.

In our environment, our tool doesn't know that gcc is being invoked.
So the solution needs to be targetted.  That's why a solution like
GCC_COLOURS would be good.  In fact, it could probably be hacked into 
GCC_COLOURS.

Man pages in section 1 that explicitly reference LC_CTYPE:
enca
enconv
find
gcc
gnroff
grep
jove
koi8rxterm
less
locale
localedef
nroff
perl5004delta
perl5160delta
perl58delta
perlfunc
perllocale
perltoc
pico
pilot
sh
systemd
time
tree
uxterm
xterm
So I feel uncomfortable setting it.

Man pages in section 1 that explicitly reference LC_MESSAGES:
apropos
aspell
awk
bash
enca
enconv
find
gawk
gcc
grep
hunspell
install-tl
locale
localectl
localedef
lynx
man
nmcli
perllocale
perltoc
sh
systemd
systemd-firstboot
time
whatis
xdg-desktop-icon
xdg-desktop-menu
So setting this would hardly be safer.



gcc-4.9-20151021 is now available

2015-10-21 Thread gccadmin
Snapshot gcc-4.9-20151021 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20151021/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 229155

You'll find:

 gcc-4.9-20151021.tar.bz2 Complete GCC

  MD5=49445cb117ab1503657dab558b438598
  SHA1=3f76f9549870dc161e8c205193b117beeec779dd

Diffs from 4.9-20151014 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


Re: UTF-8 quotation marks in diagnostics

2015-10-21 Thread Joseph Myers
On Wed, 21 Oct 2015, D. Hugh Redelmeier wrote:

>   The LC_CTYPE environment variable specifies character
>   classification.  GCC uses it to determine the character
>   boundaries in a string; this is needed for some multibyte
>   encodings that contain quote and escape characters that are
>   otherwise interpreted as a string end or escape.

That's inaccurate.  The default source encoding is always UTF-8.  See the 
comment in libcpp/charset.c.

  /* We disable this because the default codeset is 7-bit ASCII on
 most platforms, and this causes conversion failures on every
 file in GCC that happens to have one of the upper 128 characters
 in it -- most likely, as part of the name of a contributor.
 We should definitely recognize in-band markers of file encoding,
 like:
 - the appropriate Unicode byte-order mark (FE FF) to recognize
   UTF16 and UCS4 (in both big-endian and little-endian flavors)
   and UTF8
 - a "#i", "#d", "/ *", "//", " #p" or "#p" (for #pragma) to
   distinguish ASCII and EBCDIC.
 - now we can parse something like "#pragma GCC encoding 
   on the first line, or even Emacs/VIM's mode line tags (there's
   a problem here in that VIM uses the last line, and Emacs has
   its more elaborate "local variables" convention).
 - investigate whether Java has another common convention, which
   would be friendly to support.
 (Zack Weinberg and Paolo Bonzini, May 20th 2004)  */

I haven't checked whether the documentation (and the matching 
documentation for -finput-charset) was once accurate in this regard (i.e. 
if the documentation in question dates from a time when LC_CTYPE did 
determine the source character set).

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: UTF-8 quotation marks in diagnostics

2015-10-21 Thread Martin Sebor

On 10/21/2015 03:23 PM, D. Hugh Redelmeier wrote:

Several of us don't want UTF-8 quotation marks in diagnostics in our
environment (Jove subshells).  We'd like a way to turn them off.  We don't
think that they are a bad idea but they are bad in our environment.



English-language diagnostic messages will now use Unicode
quotation marks in UTF-8 locales. (Non-English messages
already used the quotes appropriate for the language in
previous releases.) If your terminal does not support UTF-8
but you are using a UTF-8 locale (such locales are the default
on many GNU/Linux systems) then you should set LC_CTYPE=C in
the environment to disable that locale. Programs that parse
diagnostics and expect plain ASCII English-language messages
should set LC_ALL=C. See Markus Kuhn's explanation of Unicode
quotation marks for more information.

This suggests that LC_CTYPE=C would do what we want: go back to ` and
' instead of 342\200\230 and \342\200\231.


That would go against the usual (i.e., POSIX) expected effect
of the environment variable.  Specifically for GCC (or the c99
utility), POSIX requires LC_CTYPE to determine the locale used
to parse the input, and LC_MESSAGE to determine the locale of
diagnostic messages.  If the c99 utility on your system doesn't
honor that I would recommend opening a bug.

Martin



Re: Proposed doc update for Explicit Reg Vars 2/3

2015-10-21 Thread David Wohlferd


I installed this patch from David with an update to use the "Registers 
are a scarce resource ..." text.


2 down, 1 to go.  Thanks.

dw