Re: GCC optimization report
Yes, in addition to what Richard said, I am working on a patch to add -fopt-report option to gcc. The first users of this optimization report are the vectorizer passes. The hope is that other passes would add important optimization info to -fopt-report later. Of course, there are various dump files as well for more detailed pass-specific information. Please see a patch in progress for vectorizer. It started out as something else, but now adds -fopt-report option for vectorizer. http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00147.html Thanks, Sharad > -- Forwarded message -- > From: Richard Guenther > Date: Tue, Jul 17, 2012 at 4:23 AM > Subject: Re: GCC optimization report > To: erotavlas_tu...@libero.it > Cc: gcc > > > On Tue, Jul 17, 2012 at 12:43 PM, wrote: >> Hi all, >> I would like to know if GCC provides an option to get a detailed report on >> the optimization actually performed by the compiler. For example with the >> Intel C compiler it is possible using the -opt-report. I don't want to look >> at the assembly file and figure out the optimization. > > There is only -ftree-vectorizer-verbose=N currently and the various > dump-files > the individual passes produce (-fdump-tree-all[-subflags] > -fdump-rtl-all[-subflags]). > > Richard. > >> Thank you >> Best Regards >> >> Salvatore >> Frandina >> >
Re: selective scheduler failure
I applied the new patch and it seams fine. Thanks! Alex --- On Wed, 7/18/12, Alexander Monakov wrote: > From: Alexander Monakov > Subject: Re: selective scheduler failure > To: "Alex Turjan" > Cc: "Alexander Monakov" , gcc@gcc.gnu.org > Date: Wednesday, July 18, 2012, 1:42 AM > On Wed, Jul 18, 2012 at 1:05 AM, Alex > Turjan > wrote: > > I found the patch from the following link: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250 > > See comment 9. The patch pasted in the audit trail is not > what has > been committed. > > Alexander >
Re: [patch] Add a lexical block only when the callsite has source location info
On Wed, Jul 18, 2012 at 1:04 AM, Dehao Chen wrote:
> Hi, Dodji,
>
> Thanks for the comments.
>
> On Tue, Jul 17, 2012 at 11:32 PM, Dodji Seketeli wrote:
>>
>> Dehao Chen writes:
>>
>> > Thanks Richard,
>> >
>> > Hi, Dodji,
>>
>> Hi Dehao,
>>
>> > In gcc, we've met many cases where location_t and block are inconsistent
>> > in
>> > the debug info. This generates very confusing addr2line results. This is
>> > mainly due to the fact that some data structures does not updates its
>> > block
>> > info as expected (e.g. phi_arg_t). I'm planning to clean this up by
>> > encoding block into the location_t. In this way, we do not need to
>> > update
>> > block whenever we do transformation. And we may even be able to
>> > eliminate
>> > the "block" field in gimple (as soon as we can derive that from
>> > location_t). To do that, we need to add a field "void *block" in
>> > expanded_location in libcpp/include/line-map.h. Do you think this is OK?
>> > Or
>> > any comments will be welcome.
>>
>> Richard, Jan, Jakub and myself discussed this on the public IRC of GCC
>> and it seems like we reached a sort of modus vivendi for this. They are
>> in CC of this message.
>>
>> I don't think you can just add a pointer to a block in the
>> expanded_location structure like that. That would imply that you'd need
>> to be able to simply associate an instance of location_t handed out
>> (encoded) by a line map, with a block. The problem is that the
>> location_t integer itself already encodes a column number and a line
>> number. And a given set of instances of location_t (those handed out by
>> a given line map) share the same line map. And a line map struct
>> carries things like the file name, whether the file is a system file,
>> etc. To decode an instance of location_t, it takes looking up which
>> line map it was encoded from. Once we have the map we can get the file
>> path from it, and we can decode the line/columns numbers directly from
>> the value of the location_t instance itself. These values are then put
>> into a newly allocated expanded_location.
>>
>> All this to say that "just" adding a pointer to the expanded_location
>> wouldn't work. You need to way to e.g. associate the location_t to the
>> block.
>
>
> Sorry that I may mis-addressed the issue. What I was saying is that adding a
> pointer to expanded_location is just the first step. We difinitely need to
> modify the linemap to associate the pointer with the location_t.
>
>>
>>
>> From our discussion, it looks like a good way to go would be to do
>> something like what the RTL infrastructure does with insn locators (e.g
>> in emit-rtl.c, starting from bloc_locators_locs and going to
>> locator_eq).
>>
>> Basically create a new "block_locator" integer that would associated
>> with a {location_t, block} pair. There would be a vector of
>> 'block_locator's. The indexes of the 'block_locator's would index a
>> vector of {location_t, block} pair. That way, looking up the
>> {location_t, block} that corresponds to a given block_location would be
>> possible. This is or a variation along these lines.
>>
>
> I got your point. But one more thing: we need to change location_t in all
> data structure into this index, right? E.g., gimple_location would return
> this index instead of original location_t? And we also want to change
> expand_location(location_t) into expand_location(index)?
The question is what to do with fold () and friends - on GENERIC we use
EXPR_LOCATION on tcc_expression nodes and a block pointer in
struct tree_exp. Now, currently fold () only has _loc variants (as you noticed)
and for correctness we'd need to pass block there, too.
So - the question is whether to avoid all this and change tree_exp.locus/block
to block_location, too (which obviously would affect frontends and all of fold).
If we don't do that all of the middle-end that uses fold () and then
force_gimple_operand () and friends would lose the block part of the location.
CC'in the ml again, this is of general interest and others may have comments.
Richard.
> An alternative approach would be simply add "block" as part of the hash
> function in the linemap. In this way, whenever the block is changed, we can
> simply add a new location_t number. The pros of this approach is that the
> changes is kept minimum. The cons of this approach is that location_t is
> globally numbered. What do you think?
>
> Thanks,
> Dehao
>
>
>>
>> There would be one such association for each current function where we
>> need it. That association would be then be saved in the function data
>> structure of the current function so we don't loose it whenever we
>> switch functions.
>>
>> The mid-term goal would then be to unify this with the insns locators
>> used by the RTL infrastructure.
>>
>> I hope this helps.
>>
>>Dodji
>> >
>> > Thanks,
>> > Dehao
>> >
>> >
>> > On Tue, Jul 17, 2012 at 5:27 PM, Richard Guenther <
>> > richard.guent...@gmail.com> wrote:
>> >
>> >> O
Re: [patch] Add a lexical block only when the callsite has source location info
On Wed, Jul 18, 2012 at 4:35 PM, Dodji Seketeli wrote:
> Dehao Chen writes:
>
>> Hi, Dodji,
>>
>> Thanks for the comments.
>
> You are welcome.
>
> [...]
>
>> We difinitely need to modify the linemap to associate the pointer with
>> the location_t.
>
> And that is the hard part. :-)
You are right, I played with line_map a little bit today, it's quite
complex and it's hard to encode anything else into it.
The reason why we wanna build an integrated block_location (of type
location_t) is that we don't want to change the fold() interface. As a
result, we need to invent a way to map an integer to {location_t,
block} pair. How about the this approach:
1. Keep the FE unchanged.
2. Add a hashmap to map {location_t, block} to block_location_idx,
which is the index to {location_t, block} array.
3. After FE, use a separate pass to build the hashmap, and convert all
EXPR_LOCATION and gimple_location from original location_t to
block_location_idx.
4. After that, all reference (read/wrrite) to EXPR_LOCATION and
gimple_location will all refer to block_location_idx instead of
location_t.
The pros of this approach:
* both FE and fold() family are kept unchanged.
The cons of this approach:
* extra storage for {location_t, block} array
* needs to be very careful during implementation, e.g. after phase 3,
nothing should reference "input_location" because it is location_t.
Any comments?
Thanks,
Dehao
>
> You can read the comments of the line_map_ordinary struct in
> libcpp/include/line-map.h to understand how a given pair of line/column
> is encoded there.
>
> The general idea is that there is no bijection between the instances
> of location_t and a given line map. Just a surjection, at best. So the idea
> of adding a block pointer to a line map won't work.
>
> For instance, if you have a translation unit without header file and
> without macro, there will be only one line map, that will encode all the
> instances of location_t needed for all the tokens of that translation
> unit. You need an association location_t <-> block for each location_t,
> sure, but then the blocks can reasonably not be stored in the unique
> line map ...
>
>>>
>>> From our discussion, it looks like a good way to go would be to do
>>> something like what the RTL infrastructure does with insn locators (e.g
>>> in emit-rtl.c, starting from bloc_locators_locs and going to
>>> locator_eq).
>>>
>>> Basically create a new "block_locator" integer that would associated
>>> with a {location_t, block} pair. There would be a vector of
>>> 'block_locator's. The indexes of the 'block_locator's would index a
>>> vector of {location_t, block} pair. That way, looking up the
>>> {location_t, block} that corresponds to a given block_location would be
>>> possible. This is or a variation along these lines.
>>>
>>>
>> I got your point. But one more thing: we need to change location_t in all
>> data structure into this index, right? E.g., gimple_location would return
>> this index instead of original location_t?
>
> I am not sure. My understanding is that this new index will just be a
> "block_locator"; for blocks. It would be only built whenever you need
> it for a block. So gimple_location should stay as is.
>
>> And we also want to change expand_location(location_t) into
>> expand_location(index)?
>
> I am not sure either. You'd be able to get the location_t from the
> block_index, so you'd just have to do something like:
>
> expand_location (block_loc_to_source_loc (block_location));
>
> where block_loc_to_source_loc would be a new function.
>
>> An alternative approach would be simply add "block" as part of the hash
>> function in the linemap.
>
> That's the crux of the issue. There is no real hash function in the
> line map. Just a monotonic (wrt line/columns) encoding that is tailored
> to avoid "holes" in the integer space used for instances of location_t,
> and minimize the memory usage of the line maps.
>
> I don't really see how you can reasonably add a block into the existing
> encoding of instances of location_t ...
>
>> In this way, whenever the block is changed, we can simply add a new
>> location_t number.
>
> Today, as the encoding is designed to avoid holes in the location_t
> space, you cannot create a new instance of location_t "in the middle" of
> the instances of location_t already created.
>
> --
> Dodji
SMS issues
Im writing to you with respect to some strange SMS functionality.
In the code bellow there are 2 instructions (a builtin store and a builtin
load)
as they appear in the program flow before SMS:
(insn 134 133 135 12 tdscdma_pfu_ccdec.c:289
(set (mem:HI (plus:PSI (reg/v/f:PSI 185 [ ccdecInterim_pi16 ])
(reg:SI 303)) [0 S2 A16])
(unspec:HI [
(reg/v:HI 244 [ outData_u16 ])
] 1752)) 1377 {INSN_BUILTIN___storebyteofs_16} (expr_list:REG_DEAD
(reg:SI 303)
(expr_list:REG_DEAD (reg/v:HI 244 [ outData_u16 ])
(nil
(insn 136 135 137 12 tdscdma_pfu_ccdec.c:292
(set (reg/v:HI 248 [ mappingAddress_i16 ])
(unspec:HI [
(mem:HI (plus:PSI (reg/v/f:PSI 170 [ curMappingTable_pi16 ])
(reg:SI 305)) [0 S2 A16])
] 696)) 755 {INSN_BUILTIN___loadbyteofs_16} (expr_list:REG_DEAD
(reg:SI 305)
(nil)))
I observed that in ddg.c there are 3 dependencies build between insn 134 and
136:
1. (T,0) - a true dep of distance 0.
2. (T,1) - a true dep of distance 1.
3. (A,1) - an anti dep of distance 1.
Due to (T,1) dependence, further on during the calling of generate_reg_moves:
1. there is created a (modulo expansion) move instruction
(insn 207 132 134 13 (set (reg:HI 326)
(mem:HI (plus:PSI (reg/v/f:PSI 185 [ ccdecInterim_pi16 ])
(reg:SI 303)) [0 S2 A16])) -1 (nil))
2. while generate_reg_moves attempts to replace in insn 136 the memory access
(mem:HI (plus:PSI (reg/v/f:PSI 170 [ curMappingTable_pi16 ])
(reg:SI 305)) [0 S2 A16])
with the register (reg:HI 326) (the same as the one set by insn 207).
But the replacement fails so insn 136 remains unchanged.
Remark that later on insn 207 gets removed (during ira)
Issues:
1. What is the reason why (T,1) is build up? – to me it seams that (T,0)
must be enough
2. Looking inside generate_reg_moves it seams to me that this function
is not meant to deal with replacing memory accesses but only with
register replacements. (see inside the call to replace_rtx which in
my case trys to replace the mem accesses inside 136).
3. The (T,1) dep is assumed to take place as if before the SMS pass,
insn 136 was preceding insn 134:
(insn 136 135 137 12 tdscdma_pfu_ccdec.c:292
(set (reg/v:HI 248 [ mappingAddress_i16 ])
(unspec:HI [
(mem:HI (plus:PSI (reg/v/f:PSI 170 [ curMappingTable_pi16 ])
(reg:SI 305)) [0 S2 A16])
] 696)) 755 {INSN_BUILTIN___loadbyteofs_16} (expr_list:REG_DEAD
(reg:SI 305)
(nil)))
(insn 134 133 135 12 tdscdma_pfu_ccdec.c:289
(set (mem:HI (plus:PSI (reg/v/f:PSI 185 [ ccdecInterim_pi16 ])
(reg:SI 303)) [0 S2 A16])
(unspec:HI [
(reg/v:HI 244 [ outData_u16 ])
] 1752)) 1377 {INSN_BUILTIN___storebyteofs_16} (expr_list:REG_DEAD
(reg:SI 303)
(expr_list:REG_DEAD (reg/v:HI 244 [ outData_u16 ])
(nil
If that would be the case then between 134 and 136 there would be present
also an antidependence of distance 0. Becasue in the pipelined schedule,
134 is scheduled before 136 (SCHED_TIME (136) > SCHED_TIME (134)) the modulo
variable expansion needs to take place as explained before.
SMS decides to produce a modulo variable expansion in a case when is not
needed. However, it fails in fulfilling the whole modulo variable expansion
procedure, covering in this way the possibly incorrect behavior described above.
regards,
Alex
gcc translator build with QT
Is there any reason that I can't create a new front-end translator for gcc using QT? Regards -- Chris Jones @ kernel.devproj...@gmail.com also on oracle.kernel...@gmail.com and netbsd.kernel...@gmail.com OpenSUSE 12.1 (Primary)|TinyCore|Slitaz|Parabola|OpenIndiana|NetBSD (PC) Android 4.0.3 (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming) Linux kernel developer|Solaris kernel developer|BSD kernel developer Lead Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web Services|Digital Imaging Services Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 controller|Logitech Attack 3 j/stick Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox PGP Fingerprint: 4E38 0776 B380 63C8 F64F A7D6 736C CF56 42A4 FB35
Re: gcc translator build with QT
On Thu, 19 Jul 2012 13:23:40 +1000
Chris Jones wrote:
> Is there any reason that I can't create a new front-end translator for
> gcc using QT?
GCC being a free GPLv3 software, you could always fork it and do that. But I am
not sure
to understand what you really are thinking of.
While current GCC is easily extensible thru plugins (or MELT extensions, see
http://gcc-melt.org/ for more), there is no plugin interface to add a new
front-end (yet).
And Qt http://qt.nokia.com/ being mostly a graphical interface toolkit, I
don't see how
it is relevant to a new front-end.
GCC has very deeply the idea that you compile compilation units (such as
toplevel C
files) in whole by parsing some files.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: gcc translator build with QT
Basile Starynkevitch wrote: On Thu, 19 Jul 2012 13:23:40 +1000 Chris Jones wrote: Is there any reason that I can't create a new front-end translator for gcc using QT? GCC being a free GPLv3 software, you could always fork it and do that. But I am not sure to understand what you really are thinking of. While current GCC is easily extensible thru plugins (or MELT extensions, see http://gcc-melt.org/ for more), there is no plugin interface to add a new front-end (yet). And Qt http://qt.nokia.com/ being mostly a graphical interface toolkit, I don't see how it is relevant to a new front-end. GCC has very deeply the idea that you compile compilation units (such as toplevel C files) in whole by parsing some files. Regards. You might remember a while ago I was asking how to implement a new language support into gcc. And it was suggested to me by several people that implementing it via a front-end and translator would be the best way to go. I was thinking of using QT Designer and QDevelop. But before I even want to make a start, I just wanted to know whether QT would be the best for this. If there's a better solution or tool available, I'm open to suggestions. Regards -- Chris Jones @ kernel.devproj...@gmail.com also on oracle.kernel...@gmail.com and netbsd.kernel...@gmail.com OpenSUSE 12.1 (Primary)|TinyCore|Slitaz|Parabola|OpenIndiana|NetBSD (PC) Android 4.0.3 (Smartphone)|Windows 7 (Laptop)|Windows XP (Gaming) Linux kernel developer|Solaris kernel developer|BSD kernel developer Lead Developer of SDL|Lead Developer of Nest Linux|Gamer and Emulator nut|Web Services|Digital Imaging Services Controllers: Rapier V2 Gaming mouse|Logitech Precision|PS3 controller|XB360 controller|Logitech Attack 3 j/stick Emulators: Fusion|Gens|ZSNES|Project64|PCSX-R|Stella|WinVICE|WinUAE|DOSBox PGP Fingerprint: 4E38 0776 B380 63C8 F64F A7D6 736C CF56 42A4 FB35
Re: gcc translator build with QT
On Thu, 19 Jul 2012 15:45:16 +1000
Chris Jones wrote:
> Basile Starynkevitch wrote:
> > On Thu, 19 Jul 2012 13:23:40 +1000
> > Chris Jones wrote:
> >
> >> Is there any reason that I can't create a new front-end translator for
> >> gcc using QT?
> > GCC being a free GPLv3 software, you could always fork it and do that. But
> > I am not sure
> > to understand what you really are thinking of.
> >
> > While current GCC is easily extensible thru plugins (or MELT extensions, see
> > http://gcc-melt.org/ for more), there is no plugin interface to add a new
> > front-end (yet).
> >
> > And Qt http://qt.nokia.com/ being mostly a graphical interface toolkit, I
> > don't see how
> > it is relevant to a new front-end.
> >
> > GCC has very deeply the idea that you compile compilation units (such as
> > toplevel C
> > files) in whole by parsing some files.
>
> You might remember a while ago I was asking how to implement a new
> language support into gcc. And it was suggested to me by several people
> that implementing it via a front-end and translator would be the best
> way to go.
You might have a confusing terminology, with regards to GCC internals.
You could implement a new language by making a translator from that language to
C (this
is actually a good idea, and I am doing that in MELT; MELT is a domain specific
language
to extend GCC, see http://gcc-melt.org/). Don't call that translator a
front-end.
You could choose to have your translator emit standard C code, then it should
generate C
code compilable by any C compiler (e.g. gcc, tcc, clang, ...).
You could also choose to have your translator emit C code with GCC extensions.
http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
Many GCC extensions are useful when emitting C code (e.g. variable length array,
labels as values & computed gotos, attributes, extended asm, builtins...); some
GCC
extensions are accepted by some other compilers (e.g. Clang). But standard
conforming
compilers should only follow the C standards (and don't provide all GCC
extensions).
If you choose to emit C code, your translator probably depends upon GCC but is
*not* a
GCC front-end; it is an independent program which happens to need GCC.
Alternatively (and probably latter, once you have a prototype implementation of
your
language), you could make a GCC front-end for your language. This requires you
to develop
a large bunch of code which is linked inside (your fork of) GCC. This also
requires you
to understand the details of GCC middle-end representations and passes.
Within the GCC community, a GCC front-end is a large bunch of code linked
inside GCC.
Look inside GCC source code, notably gcc/go/ & gcc/objc/ for examples.
A translator emitting C code for GCC should not be called a front-end.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
