Re: RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends

[Richard Guenther]

On Thu, Nov 25, 2010 at 3:32 AM, Dave Korn  wrote:
> On 24/11/2010 14:17, Richard Guenther wrote:
>
>> I don't see why RTL optimizers should be different from tree optimizers.
>
>  I thought half the point of tree-ssa in the first place was to separate
> optimisation out from target-specific stuff and do it on an independent level?
>
> On 24/11/2010 15:32, Richard Guenther wrote:
>> As we are moving towards doing more target dependent optimizations
>> on the tree level this doesn't sound like a sustainable opinion.
>
>  Wait, we're doing that?  Isn't that the same mistake we made earlier?

GIMPLE SSA is a much easier IL to work on compared to RTL and
we are (slowly) moving (early) RTL optimizations towards the tree
level (see recent changes around fma, widening multiplication, etc.).

And we do have target dependent passes on trees, like the vectorizer,
induction variable optimization, various foldings that depend on target
availability of builtins, etc.

Even all trees for decls and types are target dependent.

> On 24/11/2010 14:17, Richard Guenther wrote:
>> And we don't want to pay the overhead of hookization every target
>> dependent constant just for the odd guys who want multi-target
>> compilers that have those constants differing.
>
>  Why not?  Precisely how big is this cost?  Back in the old days we all used
> to want to avoid virtual functions, because of the cost of a
> function-call-through-pointer, but that certainly isn't justified any more and
> may not even have been then.

Well.  I don't see value in adding even small cost if there is no benefit.

I'm trying to guess what people think the benefit would be, as I think
they are just confused as of what a completely hookized backend
would allow you to do (nothing!).

>> a multi-target compiler where the hooks are in shared loadable
>> modules
>
>  It's not just Diego who envisions that, I think it would be an excellent
> long-term goal too.  And I thought that was why all the work to hookize macros
> was motivated in the first place.

What's the benefit to our users of Diegos vision?  The downside will
be a slower compiler (maybe not by much, but we get that 1-3%
slowdown every release and it adds up and people are complaining).

Richard.

>    cheers,
>      DaveK
>
>

Re: Method to test all sse2 calls?

[Rainer Orth]

"David Mathog"  writes:

> Yup, my bad, put in d where it should have been ll.  Also fixed the
> problem I induced in sse2-check.h, where too large a chunk was commented
> out, that was causing the gcc -Wall -msse2 problem.  The changed part in
> the original source was
>
>   if ((edx & bit_SSE2) && sse_os_support ())
>
> and is now:
>
> #if !defined(SOFT_SSE2)
>   if ((edx & bit_SSE2) && sse_os_support ())
> #else
>   if (sse_os_support ())
> #endif /*SOFT_SSE2*/

I wouldn't do it this way, but simply always return 1 from
sse_os_support if SOFT_SSE2.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

HPPA - strange notes added.

[Nick Hudson]

Hi,

gcc/config/pa/pa.c has

static inline void
pa_file_start_file (int want_version)
{
  if (write_symbols != NO_DEBUG)
{
  output_file_directive (asm_out_file, main_input_filename);
  if (want_version)
aputs ("\t.version\t\"01.01\"\n");
}
}

and

static void
pa_linux_file_start (void)
{
  pa_file_start_file (1);
 ...
}

Anyone know what they're for?

Thanks,
Nick
ps. please CC me as I'm not on the list.

Call for paper / GNU development room @ FOSDEM

[Dodji Seketeli]

Hello GCC hackers!

You might know it already but the 2012 edition of the FOSDEM[1]
conference is approaching. Fast. It turns out the GNU project will have
a dedicated development room this time. So it would be nice if GCC
people could talk about their work there.

Please find below the formal Call for paper of the GNU Development Room.

[1]: The Free and Open source Software Developers' European Meeting
 (FOSDEM) is a two-day event organized by volunteers to promote the
 widespread use of Free and Open Source software.

 http://www.fosdem.org/2011/.

-- 
Dodji

The Free and Open source Software Developers' European Meeting
(FOSDEM) is a two-day event organized by volunteers to promote the
widespread use of Free and Open Source software.

This year the GNU Project will be present with a development room.
The goal of the devroom is to promote discussion on the advancement of
the GNU coding standards and maintainers guidelines as well as the
packages implementing them, and strengthen the community of
maintainers and developers.

If you plan to join us at FOSDEM please tell us at fosdem2...@gnu.org.

* Important: Call for papers

  We are looking for GNU maintainers and developers willing to give a
  speech about their package in the devroom.  If you are interested
  please send us an email with the following information:

  - *Your name and contact information*.
  - *GNU package(s)* you maintain or contribute.
  - *Title* of the speech.
  - *Abstract*.  Two or three paragraphs shall be enough.
  - *Length of the speech*.  We estimate a duration of 30 minutes per
speech.  More time may be available depending on the final
schedule.  If you need more time please let us know.

  The material available in the devroom includes a video projector
  with VGA cable and wireless internet.  If you need something else
  just ask us.

  *Deadline:* abstracts shall be submitted to fosdem2...@gnu.org not
  after Wednesday 22 December 2010.

  For more information visit the page
  http://www.gnu.org/ghm/2011/fosdem/GHM.html

GCC 4.5.2 Status Report (2010-11-25)

[Richard Guenther]

Status
==

The GCC 4.5 branch is in regression and documentation fixes only mode.
A 4.5.2 release is due this year (fingers crossing).

There are no serious regressions that would block the release at the moment.
Still there are a few wrong-code bugs that can have fixes backported
from trunk.  Please go over the bugs that are assigned to yourself
and have a target milestone that includes 4.5.2 (thus a target milestone
of 4.4.5 or 4.3.6 also qualifies) and see whether there is a low-risk
fix for the 4.5 branch.

We have accumulated a bunch of new P2 regressions thanks to Zdeneks
exhaustive use of GCC options on the GCC testsuite.  We have also fixed
quite a number of serious bugs compared to the 4.5.1 release.


Quality Data


Priority  #   Change from Last Report
---   ---
P10
P2  132   + 33
P31   - 12
---   ---
Total   133   + 21


Previous Report
===

http://gcc.gnu.org/ml/gcc/2010-07/msg00440.html


The next status report will be sent by me when announcing a release candidate.

Re: Adding Leon processor to the SPARC list of processors

[Eric Botcazou]

> Sorry, I didnt note the attachment that is already your implementation.
> I thought it was the old diff.
> So: I'm ok with all. Thanks for the effort.

OK, thanks.  I'm going to conduct a bit more testing before installing it.

What are the contributors to the patch?  This is for the ChangeLog.

-- 
Eric Botcazou

Re: Adding Leon processor to the SPARC list of processors

[konrad]

On Thu, 25 Nov 2010 22:57:19  0100, Eric Botcazou  wrote:

Sorry, I didnt note the attachment that is already your implementation.

 > > I thought it was the old diff.
 > > So: I'm ok with all. Thanks for the effort.
 >
 > OK, thanks.  I'm going to conduct a bit more testing before installing it.
 >
 > What are the contributors to the patch?  This is for the ChangeLog.
  
 Contributor: "Konrad Eisele" 
  
 >
 > --
 > Eric Botcazou
 >
 >

 

gcc-4.5-20101125 is now available

[gccadmin]

Snapshot gcc-4.5-20101125 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101125/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

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

You'll find:

 gcc-4.5-20101125.tar.bz2 Complete GCC (includes all of below)

  MD5=a68f07b659dc73edbb952dafab72a5bf
  SHA1=238d9e91c9c066a29c1ef36e0f878c4482dcc668

 gcc-core-4.5-20101125.tar.bz2C front end and core compiler

  MD5=7023dd06e5db9141c590f0c1cfb742f5
  SHA1=63ed92faff61043c0e095badf820af3106dde76e

 gcc-ada-4.5-20101125.tar.bz2 Ada front end and runtime

  MD5=cada64872a8414e38ab2e4684644cec6
  SHA1=53032cab6d2630dca2597b19568c99b46ef26317

 gcc-fortran-4.5-20101125.tar.bz2 Fortran front end and runtime

  MD5=d0b75cd4144b744a7abeca36d19b9726
  SHA1=d2a1eedfb44853fb3ba21ae7e1a0b9b6a2af9ff9

 gcc-g++-4.5-20101125.tar.bz2 C++ front end and runtime

  MD5=1e793092ca05638421c21e8ad6a5a10f
  SHA1=61f630dc270ceaea057b05ea4cd8fd4bc020dd48

 gcc-java-4.5-20101125.tar.bz2Java front end and runtime

  MD5=ae7b1c9bcbe73cb50e59b2bc940b3280
  SHA1=6172f6cb4dc48bdd4d4398c5560240bd5f3ffcc4

 gcc-objc-4.5-20101125.tar.bz2Objective-C front end and runtime

  MD5=9f4ef57841ab819563003ae65a8281e3
  SHA1=6d6ff16741340f1b75926f269868f1f3353d4a43

 gcc-testsuite-4.5-20101125.tar.bz2   The GCC testsuite

  MD5=aba643dac79c35eb7f69a027c8dc0ed7
  SHA1=735eea55e46b08db3813f4fc41e519b26c2d5104

Diffs from 4.5-20101118 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
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.

profiledbootstrap fails in java with "error: verification failed at PC=8: branch out of range"

[Uros Bizjak]

Hello!

/home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
In class 'gnu.java.awt.peer.gtk.GtkComponentPeer':
/home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
In method 
'gnu.java.awt.peer.gtk.GtkComponentPeer.handleEvent(java.awt.AWTEvent)':
In file included from :63:0:
/home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:279:0:
error: verification failed at PC=8: branch out of range
/home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:279:0:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gmake[5]: *** [gnu-java-awt-peer-gtk.lo] Error 1

Any info what this verification error means?

Thanks,
Uros.

Re: Loop-iv.c ICEs on subregs

[Zdenek Dvorak]

Hi,

> I'm investigating an ICE in loop-iv.c:get_biv_step().  I hope you can shed 
> some light on what the correct fix would be.
> 
> The ICE happens when processing:
> ==
> (insn 111 (set (reg:SI 304)
>(plus (subreg:SI (reg:DI 251) 4)
>  (const_int 1
> 
> (insn 177 (set (subreg:SI (reg:DI 251))
>(reg:SI 304)))
> ==
> 
> The code like the above does not occur on current mainline early enough for 
> loop-iv.c to catch it.  The subregs above are produced by Tom's (CC'ed) 
> extension elimination pass (scheduled before fwprop1) which is not in 
> mainline yet [*].
> 
> The failure is due to assert in loop-iv.c:get_biv_step():
> ==
> gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
> ==
> i.e., inner and outer modes can differ iff there's an extend in the chain. 
> 
> Get_biv_step_1() starts with insn 177, then gets to insn 111, then loops back 
> to insn 177 at which point it stops and returns GRD_MAYBE_BIV and sets:
> 
> * outer_mode == DImode == natural mode of (reg A);
> 
> * inner_mode == SImode == mode of (subreg (reg A)), set in get_biv_step_1:
> ==
>   if (GET_CODE (next) == SUBREG)
> {
>   enum machine_mode amode = GET_MODE (next);
> 
>   if (GET_MODE_SIZE (amode) > GET_MODE_SIZE (*inner_mode))
>   return false;
> 
>   *inner_mode = amode;
>   *inner_step = simplify_gen_binary (PLUS, outer_mode,
>*inner_step, *outer_step);
>   *outer_step = const0_rtx;
>   *extend = UNKNOWN;
> }
> ==
> 
> * extend == UNKNOWN as there are no extensions in the chain.
> 
> It seems to me that computations of outer_mode and extend are correct, I'm 
> not sure about inner_mode.
> 
> Zdenek, what do you think is the right way to handle the above case in loop 
> analysis?

loop iv analysis currently does not handle assignments to subregs; we test for
that in iv_get_reaching_def, but the corresponding test is missing in
latch_dominating_def.  I.e., a simple fix is to add

if (single_rd && (DF_REF_FLAGS (single_rd) & DF_REF_READ_WRITE))
  return false;

at the end of latch_dominating_def.  On the other hand, this means that the
loops using the code like above will not get optimized.  So, if such a code
gets produced consistently for a large fraction of the loops, it would be
necessary to teach loop-iv to analyze induction variables represented in
subregs.  This would mean a more involved rewrite of loop-iv, though,

Zdenek

Re: Loop-iv.c ICEs on subregs

[Maxim Kuvyrkov]

On Nov 26, 2010, at 3:51 AM, Zdenek Dvorak wrote:

> Hi,
> 
>> I'm investigating an ICE in loop-iv.c:get_biv_step().  I hope you can shed 
>> some light on what the correct fix would be.
>> 
>> The ICE happens when processing:
>> ==
>> (insn 111 (set (reg:SI 304)
>>   (plus (subreg:SI (reg:DI 251) 4)
>> (const_int 1
>> 
>> (insn 177 (set (subreg:SI (reg:DI 251))
>>   (reg:SI 304)))
>> ==
...
> 
> loop iv analysis currently does not handle assignments to subregs
...
> So, if such a code
> gets produced consistently for a large fraction of the loops, it would be
> necessary to teach loop-iv to analyze induction variables represented in
> subregs.  This would mean a more involved rewrite of loop-iv, though,

I see.  In that case a simpler way to fix the problem may be to move Tom's 
extension elimination pass /after/ loop optimizers.  Do you (or anyone reading 
this thread) have suggestions on what would be a good spot in the optimization 
pipeline for sign- and zero-extension elimination pass?

Thanks,

--
Maxim Kuvyrkov
CodeSourcery
+1-650-331-3385 x724