headers
Joel Sherrill | 1 Jun 2010 01:12
Gravatar

Re: Using C++ in GCC is OK

On 05/31/2010 04:36 PM, Thomas Neumann wrote:
>> Well anyone can think anything, but this view is way out of the
>> mainstream. I do not know of a single large real project using a
>> large complex language that does not have coding standards that
>> limit the use of the language.
>>      
> I know this, but I do not understand this. I have worked in reasonably large
> commercial projects. Admittedly only one had had more than a hundred active
> developers (which in fact was the one with the most loose coding standards).
> But as far as I have seen it coding standards are either in the spirit of
> what I had proposed (emphasizing code quality over language features) or are
> an over-detailed mess that is a pain in practice and gives no reasonable
> justification for the imposed limitations. I would like to prevent the later
> for GCC.
>
> But this is getting off-topic, GCC will probably limit itself to "C with
> classes" anyway. Which in my opinion is a shame, but such is life.
>
>    
Maybe I am reading too much into what Mark has been
saying but from a practical view, nothing is going to happen
quickly.  Maybe the question shouldn't be phrased in terms
that make it sound like a C++ feature will never be used but
in terms of which have the clearest near-term impact.   So
this is defining the first set of C++ features to use.

We should not open the floodgate to every C++
feature without due consideration.  Focus on features that
are easy to take advantage of in the code now and have
high payback on maintainability and readability.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Bosscher | 1 Jun 2010 01:25
Picon

Re: Using C++ in GCC is OK

On Tue, Jun 1, 2010 at 1:12 AM, Joel Sherrill <joel.sherrill <at> oarcorp.com> wrote:
> Another thing that has bothered me is the fear of
> getting slower.  If using C++ makes GCC slower, then
> GCC C++ needs to get faster.  This is eating our own
> dog food. :)

Indeed. If we can avoid the obvious problems (vtables, etc.) there is
no reason why using C++ should lead to a slower compiler. If we can
properly hide some things better, maybe we can even help our own
optimizers.  With some of the union tricks GCC plays now, GCC has to
make the worst-case assumptions when building itself. If we can solve
this with C++ we may actually get a faster compiler! (fingers
crossed...)

Things like bootstrapping with LTO (in whopr more, hopefully the
default for GCC 4.6?) may also help reduce the potential extra
overhead of using C++.

Ciao!
Steven
Permalink | Reply | 0 comments |
headers
Larry Evans | 1 Jun 2010 01:29

Re: Using C++ in GCC is OK

On 05/31/10 14:30, Basile Starynkevitch wrote:
[snip]
 > I would believe that replacing a complex function like above (which
 > contains a switch) with a virtual function call could probably be a win
 > in performance, not a loose.
 >
 > But perhaps my intuition is wrong. Honestly, I don't have exact figures
 > of the cost of virtual calls. IIRC, they have been costly for Intel
 > processors more than 5 years ago (but AMD processors perhaps run them
 > quicker at that time), but current Intel & AMD processors probably deal
 > better with indirect jump, so a virtual call is perhaps a with w.r.t. a
 > complex switch like above.
[snip]
The following post to the boost devel list:

http://sourceforge.net/mailarchive/message.php?msg_name=3f49a9f41003031715g19a23b94p47ccec2251acd55%40mail.gmail.com

claims that switch statements are faster than virtual function calls.

There's also this boost devel list post:

http://lists.boost.org/Archives/boost/2008/01/132074.php

where, instead of a virtual function table, a vector of function
pointers is used.  Using this method, I assume, would have a speed
comparable to that of using a virtual function table since a virtual
function table, IIUC, is essentially a vector of function pointers.
However, that boost devel post claims using a switch statement would
be faster.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gabriel Dos Reis | 1 Jun 2010 01:43

Re: Using C++ in GCC is OK

On Mon, May 31, 2010 at 6:29 PM, Larry Evans <cppljevans <at> suddenlink.net> wrote:

> However, that boost devel post claims using a switch statement would
> be faster.

Switching to C++ should never be excuse to bring more more brittle codes
or more obscurities.  Rather, it should be opportunity to write simpler and
better code.

The compiler has gotten better lately in devirtualization.  We are the compiler
guys.  If our implementation shows that we can do better with virtual functions,
then we should be improving the compiler -- not only we get a faster compiler,
but for the end user we get a compiler that generates much better code.  And
that is a win win.  None of that should be construed as an argument for using
virtual functions in GCC.  Rather, it is argument for resisting
desperate actions.
Permalink | Reply | 0 comments |
headers
H.J. Lu | 1 Jun 2010 02:17
Picon

Re: How to find out register information at the beginning of a basic block?

On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov <vmakarov <at> redhat.com> wrote:
> H.J. Lu wrote:
>>
>> Hi,
>>
>> I am working on generating vzeroupper to avoid AVX->SSE transition
>> penalty.
>>
>> I have generated vzeroupper on function return as well as function
>> call.  I am working on a backend pass to eliminate those vzeroupper
>> instructions when I can prove that the upper 128bits of AVX registers
>> are dead at the point where vzeroupper is added. To do that, I need
>> to find out if a register is live at the beginning of a basic block as
>> well
>> as its size. I thought dataflow might give me such info. But I couldn't
>> find a way to access such information. Does anyone have any pointers?
>>
>>
>
> DF_LR_IN (bb) returns bitmap of livings prseudo regnos.
> DF_LIVE_IN (bb) takes availability info into account.
>
> Size of hard registers is defined by hard_regno_nregs.
>

My impression is hard_regno_nregs tells me that number of
hard registers given machine mode occupy. It doesn't tell me
the live size of a hard register at the beginning of a basic
block. How do I get this information?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jie Zhang | 1 Jun 2010 02:42

Question on REG_EQUAL documentation

The GCC internal document says [1]:

[quote]
In the early stages of register allocation, a REG_EQUAL note is changed 
into a REG_EQUIV note if op is a constant and the insn represents the 
only set of its destination register.

Thus, compiler passes prior to register allocation need only check for 
REG_EQUAL notes and passes subsequent to register allocation need only 
check for REG_EQUIV notes.
[/quote]

But I still find REG_EQUAL notes in RTL dumps for those passes after 
IRA. My understanding is: a REG_EQUAL note is changed into a REG_EQUIV 
note in IRA when possible, but the remaining REG_EQUAL notes are still 
kept around. So the compiler passes after register allocation need check 
for both REG_EQUIV notes and REG_EQUAL notes. Is my understanding correct?

[1] http://gcc.gnu.org/onlinedocs/gccint/Insns.html#index-REG_005fEQUIV-2258

--

-- 
Jie Zhang
CodeSourcery
(650) 331-3385 x735
Permalink | Reply | 0 comments |
headers
Geert Bosch | 1 Jun 2010 04:12
Favicon

Re: [RFC] Switching implementation language to C++


On May 31, 2010, at 14:25, Mark Mitchell wrote:
> That doesn't necessarily mean that we have to use lots of C++ features
> everywhere.  We can use the C (almost) subset of C++ if we want to in
> some places.  As an example, if the Fortran folks want to use C in the
> Fortran front-end, then -- except to the extent required by the common
> interfaces, those files could read as if they were C code.  But, I think
> they'd still need to be compiled with a C++ compiler because they'll
> probably pull in headers that use C++ constructs.

I don't see why the implementation language of the front end should
necessarily be tied to that of the back end. One of the benefits we
should get from switching implementation language is a cleaner interface
between the language-specific parts of the compiler and the shared
back end files.

For the Ada compiler, we've never found it a disadvantage to use
Ada as implementation language, even though the back end is written 
in C. The hard parts of mapping Ada idioms to the intermediate 
languages used in the back end have never been related to the language
used for implementing the front end or back end. If anything, 
the strict separation between front end and back end data 
structures  has helped avoiding inadvertent reuse of representations
for constructs with similar yet subtly different properties.

Ideally, when having a full C++ definition of the back end interface,
we can use straight type and function definitions, instead of webs 
of header files with macro definitions. Maybe, some day, we could
even use Ada directly to interface with libbackend, eliminating the 
last remaining non-Ada code in the Ada front end.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vladimir N. Makarov | 1 Jun 2010 05:09
Picon
Favicon

Re: How to find out register information at the beginning of a basic block?

On 05/31/2010 08:17 PM, H.J. Lu wrote:
> On Mon, May 31, 2010 at 12:31 PM, Vladimir Makarov<vmakarov <at> redhat.com>  wrote:
>    
>> H.J. Lu wrote:
>>      
>>> Hi,
>>>
>>> I am working on generating vzeroupper to avoid AVX->SSE transition
>>> penalty.
>>>
>>> I have generated vzeroupper on function return as well as function
>>> call.  I am working on a backend pass to eliminate those vzeroupper
>>> instructions when I can prove that the upper 128bits of AVX registers
>>> are dead at the point where vzeroupper is added. To do that, I need
>>> to find out if a register is live at the beginning of a basic block as
>>> well
>>> as its size. I thought dataflow might give me such info. But I couldn't
>>> find a way to access such information. Does anyone have any pointers?
>>>
>>>
>>>        
>> DF_LR_IN (bb) returns bitmap of livings prseudo regnos.
>> DF_LIVE_IN (bb) takes availability info into account.
>>
>> Size of hard registers is defined by hard_regno_nregs.
>>
>>      
> My impression is hard_regno_nregs tells me that number of
> hard registers given machine mode occupy. It doesn't tell me
> the live size of a hard register at the beginning of a basic
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Mitchell | 1 Jun 2010 05:36

Re: [RFC] Switching implementation language to C++

Geert Bosch wrote:

> If we're just going to get some new power tools for our workshop
> and let people have at it, the lessons we'll learn might end up
> being more about what not to do, rather than a show case of their
> effective use.

That's why we're not doing that.  Instead, we're going to determine what
subset of C++ we're comfortable using, and then we're going to let
people propose ways of using that subset.  Nobody's suggesting letting
people run around using their favorite C++ features in random ways.

This is a chicken-egg thing.  We couldn't reasonably ask people to start
proposing ways of using C++ without knowing that the SC would allow it
to be used.  Now we've got that approval, and now people can suggest uses.

I've already implicitly suggested one, namely, using single inheritance
to implement the tree data structures, thereby avoiding casts up and
down the hierarchy.  Including, for example, declaring a routine that's
supposed to take a DECL as taking a tree_decl&, instead of just a tree *.

--

-- 
Mark Mitchell
CodeSourcery
mark <at> codesourcery.com
(650) 331-3385 x713
Permalink | Reply | 0 comments |
headers
Basile Starynkevitch | 1 Jun 2010 06:37

Re: possible license issue (documentation generated from source) in MELT branch of GCC

On Mon, 2010-05-31 at 22:46 +0200, Basile Starynkevitch wrote:
> 
> I did wrote on http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02442.html
> about the patch I intend to apply to the MELT branch (changing copyright
> notice of gcc/melt/warmelt*.melt files there).
> 
> I also emailed karl <at> gnu.org about that.

I have been asked by Karl Berry to wait several days before making that
patch. So I will.

Cheers.

--

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Permalink | Reply | 0 comments |

Gmane