Improvement of Cortex-A15
I want to do some optimizations for Cortex-A15,Is anyone doing this too or is there any work has been done? Yang Yueming
RE: readonly register
In fact my final purpose is to replace $INP by a register bank in order to be able to read several inputs using pipelined instructions (and instruction scheduler). The fixed reg solution will prevent me from doing this. Is there another way to prevent the use of some registers during the reload pass without turning them into fixed register ? Selim -Message d'origine- De : Ian Lance Taylor [mailto:i...@google.com] Envoyé : jeudi 19 janvier 2012 00:17 À : BELBACHIR Selim Cc : gcc@gcc.gnu.org Objet : Re: readonly register BELBACHIR Selim writes: > I'm trying to support an 'in' instruction which reads a value on a peripheral > and writes it into a $INP register. > The $INP register can be used in almost every insn as input operand (add, > sub, mul ...). > I defined a builting to access the 'in' instruction. > > How should I express to gcc that the $INP register can only be 'read' and > must never be written? > > For the moment, I encounter a problem during IRA pass where some of my > 'classic' registers are reloaded into $INP (apparently because I have no > register left). If you have a builtin to access the value, then you should be able to make it a fixed register. The register allocator will never try to allocate a fixed register. Ian
Fortran Compil;er
Hello, I have a system with Suse 10.3 and gcc version 4.2.1. Will there be inbuilt fortran compiler or do I have to install it separately. Thanks
Re: auto-vectorization analysis/__builtin_assume_aligned on gcc-4.7-20120114
On Wed, Jan 18, 2012 at 6:37 PM, Alexander Herz wrote:
> Given this piece of code (gcc-4.7-20120114):
>
> static void Test(Batch* block,Batch* new_block,const uint32 offs)
> {
>
> T* __restrict old_values
> =(T*)__builtin_assume_aligned(block->items,16);
> T* __restrict new_values
> =(T*)__builtin_assume_aligned(new_block->items,16);
>
> //assert(((uint64)(&block->items)%16)==0); //OK!!
> //assert(((uint64)(&new_block->items)%16)==0);
>
> for(uint32 c=0;c<(BS<<1);c++) //hopefully compiler applies SIMD here
> {
> new_values[c]=old_values[c]*old_values[c];
> }
>
> }
>
> I would assume that the loop is always vectorized (pointers tagged as
> restricted and aligned, loop
> over fixed iteration space even a power of 2, so most likely dividable by
> 4), it is quite similar to vectorization example22
> (http://gcc.gnu.org/projects/tree-ssa/vectorization.html#vectorizab).
>
> I run the previously mentioned g++ version with this command line:
> -std=c++0x -g -O3 -msse -msse2 -msse3 -msse4.1 -Wall -Wstrict-aliasing=2
> -ftree-vectorizer-verbose=2
>
> Looking at the vectorizer output (and at the generated assembly) it looks as
> if the loop given above
> is indeed vectorized if Test() is called from main() (vectorized 1 loop).
>
> When the function Test() is called nested inside some complex code, it looks
> as if the vectorization analysis gives up because the code is too complex to
> analyze and never considers the loop inside Test() in this context even
> though it should be easily vectorizeable in any context given the hints
> inside Test().
>
> Is there anything I can do, so that Test() is analyzed in all contexts? I
> guess all methods that contain the
> __builtin_assume_aligned hint should be considered for vectorization,
> independent of their context.
Without a concrete example it is impossible to say. I suppose earlier
optimizations destroy loop structure too much?
> Thx for your help,
> Alex
>
>
Re: Fortran Compil;er
On 19 January 2012 10:21, tintu david joy wrote: > Hello, > > I have a system with Suse 10.3 and gcc version 4.2.1. Will there be > inbuilt fortran compiler or do I have to install it separately. Thanks This question is unsuitable for this mailing list, please use the gcc-h...@gcc.gnu.org list for questions about using or installing GCC. This question would probably be better on a SuSE forum, since you're asking something specific to SuSE. Most GNU/Linux distributions split GCC into several packages, so you might just have the core compiler components and the C compiler. Use your system's package manager to search for "fortran" and you should find the gcc fortran package.
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
On Thu, Jan 19, 2012 at 7:37 AM, Marc Glisse wrote: > On Wed, 18 Jan 2012, willus.com wrote: > >> For those who might be interested, I've recently benchmarked gcc 4.6.3 >> (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: >> >> http://willus.com/ccomp_benchmark2.shtml > > > http://en.wikipedia.org/wiki/Microsoft_Windows_SDK#64-bit_development > > For the math functions, this is normally more a libc feature, so you might > get very different results on different OS. Then again, by using > -ffast-math, you allow the math functions to return any random value, so I > can think of ways to make it even faster ;-) Also for math functions you can simply substitute the Intel compilers one (GCC uses the Microsoft ones) by linking against libimf. You can also make use of their vectorized variants from GCC by specifying -mveclibabi=svml and link against libimf (the GCC autovectorizer will then use the routines from the Intel compiler math library). That makes a huge difference for code using functions from math.h. Richard. > -- > Marc Glisse
Access to source code from an analyser
Hello. I'm developing a C++ analyzer and I would like to get source text of file when I'm analyzing C++ code. When I'm analyzing source code I would like to get source text line from a location of a type. I have got type location but I don't know a function to get source line text from source location (file and line). I'm looking in /libcpp. Is there a function to get source text line from source location? Thanks.
Re: Access to source code from an analyser
On Thu, Jan 19, 2012 at 12:56 PM, Alberto Lozano Alelu wrote: > Hello. > > I'm developing a C++ analyzer and I would like to get source text of > file when I'm analyzing C++ code. > > When I'm analyzing source code I would like to get source text line > from a location of a type. I have got type location but I don't know a > function to get source line text from source location (file and line). > I'm looking in /libcpp. > > Is there a function to get source text line from source location? expand_location () > Thanks.
Hashing regs and subregs
Hi, I am developing a new pass and looking for suggestions on the best way to record in a data structure which regs and subregs I have seen and which mode they are in through the insn chain so I know if I find duplicates. Any suggestions on the best way to do this? Are there any rtx hashes already implemented somewhere? Cheers, -- PMatos
Re: Access to source code from an analyser
Hello.
Thanks for your fast response.
With expand_location I get struct expanded_location which has these fields:
type = struct {
const char *file;
int line;
int column;
unsigned char sysp;
}
But it hasn't source line text.
I know how I have to use expand_location function but I would like to
get source text from a source location. I would like a funcion such
as:
char *v_line_text = (file,line);
or
expanded_location v_location=expand_location(SOURCE_LOCATION(my_element));
char * v_line_text = a_function(v_location);
v_line_text is a source code line.
I need to have source text
Thanks you very much.
On 19 January 2012 13:12, Richard Guenther wrote:
> On Thu, Jan 19, 2012 at 12:56 PM, Alberto Lozano Alelu
> wrote:
>> Hello.
>>
>> I'm developing a C++ analyzer and I would like to get source text of
>> file when I'm analyzing C++ code.
>>
>> When I'm analyzing source code I would like to get source text line
>> from a location of a type. I have got type location but I don't know a
>> function to get source line text from source location (file and line).
>> I'm looking in /libcpp.
>>
>> Is there a function to get source text line from source location?
>
> expand_location ()
>
>> Thanks.
Re: auto-vectorization analysis/__builtin_assume_aligned on gcc-4.7-20120114
The generated non-vectorized assembly is simply the unrolled loop with
>8 iterations, so loop structure is pretty much intact (except for
unrolling).
Does the vectorizer fail on unrolled loops?
I can compile some assembly dumps showing both the vectorized and the
unvectorized loop?
Alex
On 01/19/2012 11:29 AM, Richard Guenther wrote:
On Wed, Jan 18, 2012 at 6:37 PM, Alexander Herz wrote:
Given this piece of code (gcc-4.7-20120114):
static void Test(Batch* block,Batch* new_block,const uint32 offs)
{
T* __restrict old_values
=(T*)__builtin_assume_aligned(block->items,16);
T* __restrict new_values
=(T*)__builtin_assume_aligned(new_block->items,16);
//assert(((uint64)(&block->items)%16)==0); //OK!!
//assert(((uint64)(&new_block->items)%16)==0);
for(uint32 c=0;c<(BS<<1);c++) //hopefully compiler applies SIMD here
{
new_values[c]=old_values[c]*old_values[c];
}
}
I would assume that the loop is always vectorized (pointers tagged as
restricted and aligned, loop
over fixed iteration space even a power of 2, so most likely dividable by
4), it is quite similar to vectorization example22
(http://gcc.gnu.org/projects/tree-ssa/vectorization.html#vectorizab).
I run the previously mentioned g++ version with this command line:
-std=c++0x -g -O3 -msse -msse2 -msse3 -msse4.1 -Wall -Wstrict-aliasing=2
-ftree-vectorizer-verbose=2
Looking at the vectorizer output (and at the generated assembly) it looks as
if the loop given above
is indeed vectorized if Test() is called from main() (vectorized 1 loop).
When the function Test() is called nested inside some complex code, it looks
as if the vectorization analysis gives up because the code is too complex to
analyze and never considers the loop inside Test() in this context even
though it should be easily vectorizeable in any context given the hints
inside Test().
Is there anything I can do, so that Test() is analyzed in all contexts? I
guess all methods that contain the
__builtin_assume_aligned hint should be considered for vectorization,
independent of their context.
Without a concrete example it is impossible to say. I suppose earlier
optimizations destroy loop structure too much?
Thx for your help,
Alex
Re: Access to source code from an analyser
On Thu, Jan 19, 2012 at 2:06 PM, Alberto Lozano Alelu wrote:
> Hello.
>
> Thanks for your fast response.
>
> With expand_location I get struct expanded_location which has these fields:
> type = struct {
> const char *file;
> int line;
> int column;
> unsigned char sysp;
> }
>
> But it hasn't source line text.
>
> I know how I have to use expand_location function but I would like to
> get source text from a source location. I would like a funcion such
> as:
>
> char *v_line_text = (file,line);
>
> or
>
> expanded_location v_location=expand_location(SOURCE_LOCATION(my_element));
> char * v_line_text = a_function(v_location);
>
> v_line_text is a source code line.
>
> I need to have source text
There is no such thing.
Richard.
> Thanks you very much.
>
> On 19 January 2012 13:12, Richard Guenther wrote:
>> On Thu, Jan 19, 2012 at 12:56 PM, Alberto Lozano Alelu
>> wrote:
>>> Hello.
>>>
>>> I'm developing a C++ analyzer and I would like to get source text of
>>> file when I'm analyzing C++ code.
>>>
>>> When I'm analyzing source code I would like to get source text line
>>> from a location of a type. I have got type location but I don't know a
>>> function to get source line text from source location (file and line).
>>> I'm looking in /libcpp.
>>>
>>> Is there a function to get source text line from source location?
>>
>> expand_location ()
>>
>>> Thanks.
Re: auto-vectorization analysis/__builtin_assume_aligned on gcc-4.7-20120114
On Thu, Jan 19, 2012 at 2:12 PM, Alexander Herz wrote:
> The generated non-vectorized assembly is simply the unrolled loop with >8
> iterations, so loop structure is pretty much intact (except for unrolling).
>
> Does the vectorizer fail on unrolled loops?
>
> I can compile some assembly dumps showing both the vectorized and the
> unvectorized loop?
Assembly does not help. Loop unrolling happens after vectorization.
Richard.
> Alex
>
>
> On 01/19/2012 11:29 AM, Richard Guenther wrote:
>>
>> On Wed, Jan 18, 2012 at 6:37 PM, Alexander Herz
>> wrote:
>>>
>>> Given this piece of code (gcc-4.7-20120114):
>>>
>>> static void Test(Batch* block,Batch* new_block,const uint32 offs)
>>> {
>>>
>>> T* __restrict old_values
>>> =(T*)__builtin_assume_aligned(block->items,16);
>>> T* __restrict new_values
>>> =(T*)__builtin_assume_aligned(new_block->items,16);
>>>
>>> //assert(((uint64)(&block->items)%16)==0); //OK!!
>>> //assert(((uint64)(&new_block->items)%16)==0);
>>>
>>> for(uint32 c=0;c<(BS<<1);c++) //hopefully compiler applies SIMD
>>> here
>>> {
>>> new_values[c]=old_values[c]*old_values[c];
>>> }
>>>
>>> }
>>>
>>> I would assume that the loop is always vectorized (pointers tagged as
>>> restricted and aligned, loop
>>> over fixed iteration space even a power of 2, so most likely dividable by
>>> 4), it is quite similar to vectorization example22
>>> (http://gcc.gnu.org/projects/tree-ssa/vectorization.html#vectorizab).
>>>
>>> I run the previously mentioned g++ version with this command line:
>>> -std=c++0x -g -O3 -msse -msse2 -msse3 -msse4.1 -Wall -Wstrict-aliasing=2
>>> -ftree-vectorizer-verbose=2
>>>
>>> Looking at the vectorizer output (and at the generated assembly) it looks
>>> as
>>> if the loop given above
>>> is indeed vectorized if Test() is called from main() (vectorized 1 loop).
>>>
>>> When the function Test() is called nested inside some complex code, it
>>> looks
>>> as if the vectorization analysis gives up because the code is too complex
>>> to
>>> analyze and never considers the loop inside Test() in this context even
>>> though it should be easily vectorizeable in any context given the hints
>>> inside Test().
>>>
>>> Is there anything I can do, so that Test() is analyzed in all contexts? I
>>> guess all methods that contain the
>>> __builtin_assume_aligned hint should be considered for vectorization,
>>> independent of their context.
>>
>> Without a concrete example it is impossible to say. I suppose earlier
>> optimizations destroy loop structure too much?
>>
>>> Thx for your help,
>>> Alex
>>>
>>>
>
Re: Access to source code from an analyser
On Thu, 2012-01-19 at 14:06 +0100, Alberto Lozano Alelu wrote:
> Hello.
>
> Thanks for your fast response.
>
> With expand_location I get struct expanded_location which has these fields:
> type = struct {
> const char *file;
> int line;
> int column;
> unsigned char sysp;
> }
>
> But it hasn't source line text.
>
> I know how I have to use expand_location function but I would like to
> get source text from a source location. I would like a funcion such
> as:
>
> char *v_line_text = (file,line);
>
> or
>
> expanded_location v_location=expand_location(SOURCE_LOCATION(my_element));
> char * v_line_text = a_function(v_location);
>
> v_line_text is a source code line.
>
> I need to have source text
I'm interested in hearing if there's a more "official" way of doing this
from the GCC experts, but can't you just read the file from disk and
split it on newline characters? (probably with some caching)
FWIW, in my Python plugin [1] for GCC I created a helper function:
def get_src_for_loc(loc):
# Given a gcc.Location, get the source line as a string
import linecache
return linecache.getline(loc.file, loc.line).rstrip()
which uses Python's linecache module to do the heavy lifting (in
particular, it adds the caching).
[snip]
Dave
[1] https://fedorahosted.org/gcc-python-plugin/
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
Hello! > > For the math functions, this is normally more a libc feature, so you might > > get very different results on different OS. Then again, by using > > -ffast-math, you allow the math functions to return any random value, so I > > can think of ways to make it even faster ;-) > > Also for math functions you can simply substitute the Intel compilers one > (GCC uses the Microsoft ones) by linking against libimf. You can also make > use of their vectorized variants from GCC by specifying -mveclibabi=svml > and link against libimf (the GCC autovectorizer will then use the routines > from the Intel compiler math library). That makes a huge difference for > code using functions from math.h. However, even with -mveclibabi=svml, we still don't vectorize the call to sincos ... >From [1], it looks that the transcendental performance mostly depends on math library code. I wonder if libimf handles calls with AVX arguments to vectorized functions, so we can extend libimf support code in gcc. [1] http://willus.com/ccomp_benchmark2.shtml?p19 Uros.
Dealing with compilers that pretend to be GCC
Hello, A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them. I had the following macro to determine whether plug-in support is available: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markup&revision=5169&root=starpu&pathrev=5202 The macro is fairly elaborate. Yet, ICC 12.0.1 and Clang 3.4 both pass the test, because: - They support ‘--version’; - They define ‘__GNUC__’, which defeats Autoconf’s ‘_AC_LANG_COMPILER_GNU’. - They support ‘-print-file-name’, and have ‘-print-file-name=plugin’ return GCC’s (!) plug-in header directory. To that end, ICC simply runs ‘gcc -print-file-name=plugin’, while Clang appears to be doing some guesswork. It turns out that ICC manages to build a working GCC plug-in, so after all, it may be “entitled” to define ‘__GNUC__’, in a broad sense. Conversely, Clang doesn’t support several GNU extensions, such as nested functions, so it quickly fails to compile code. Based on that, I modified my feature test like this: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=5169&r2=5203 I don’t see what can be done on “our” side (perhaps Autoconf’s feature test could be strengthened, but how?), but I wanted to document this state of affairs. Thanks, Ludo’.
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
On 1/19/2012 2:59 AM, Richard Guenther wrote: On Thu, Jan 19, 2012 at 7:37 AM, Marc Glisse wrote: On Wed, 18 Jan 2012, willus.com wrote: For those who might be interested, I've recently benchmarked gcc 4.6.3 (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: http://willus.com/ccomp_benchmark2.shtml http://en.wikipedia.org/wiki/Microsoft_Windows_SDK#64-bit_development For the math functions, this is normally more a libc feature, so you might get very different results on different OS. Then again, by using -ffast-math, you allow the math functions to return any random value, so I can think of ways to make it even faster ;-) Also for math functions you can simply substitute the Intel compilers one (GCC uses the Microsoft ones) by linking against libimf. You can also make use of their vectorized variants from GCC by specifying -mveclibabi=svml and link against libimf (the GCC autovectorizer will then use the routines from the Intel compiler math library). That makes a huge difference for code using functions from math.h. Richard. -- Marc Glisse Thank you both for the tips. Are you certain that with the flags I used Intel doesn't completely in-line the math2.h functions at the compile stage? gcc? I take it to use libimf.a (legally) I would have to purchase the Intel compiler?
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
On Thu, Jan 19, 2012 at 3:27 PM, willus.com wrote: > On 1/19/2012 2:59 AM, Richard Guenther wrote: >> >> On Thu, Jan 19, 2012 at 7:37 AM, Marc Glisse wrote: >>> >>> On Wed, 18 Jan 2012, willus.com wrote: >>> For those who might be interested, I've recently benchmarked gcc 4.6.3 (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: http://willus.com/ccomp_benchmark2.shtml >>> >>> >>> http://en.wikipedia.org/wiki/Microsoft_Windows_SDK#64-bit_development >>> >>> For the math functions, this is normally more a libc feature, so you >>> might >>> get very different results on different OS. Then again, by using >>> -ffast-math, you allow the math functions to return any random value, so >>> I >>> can think of ways to make it even faster ;-) >> >> Also for math functions you can simply substitute the Intel compilers one >> (GCC uses the Microsoft ones) by linking against libimf. You can also >> make >> use of their vectorized variants from GCC by specifying -mveclibabi=svml >> and link against libimf (the GCC autovectorizer will then use the routines >> from the Intel compiler math library). That makes a huge difference for >> code using functions from math.h. >> >> Richard. >> >>> -- >>> Marc Glisse > > Thank you both for the tips. Are you certain that with the flags I used > Intel doesn't completely in-line the math2.h functions at the compile stage? Yes. Intel merely comes with its own (optimized) math library while GCC has to rely on the operating system one. > gcc? I take it to use libimf.a (legally) I would have to purchase the > Intel compiler? I would say you have to purchase the Intel compiler. Even then the license to use libimf.a may be restricted. So I wouldn't recomment distributing binaries linked with libimf.a without consulting a lawyer. Richard.
Re: Dealing with compilers that pretend to be GCC
Hi Ludo, A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them. this suggests that you shouldn't be testing for GCC, and instead should be testing for support for particular features. For example, to know if nested functions are supported you would have your configure script compile a mini program that uses nested functions. Ciao, Duncan. I had the following macro to determine whether plug-in support is available: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markup&revision=5169&root=starpu&pathrev=5202 The macro is fairly elaborate. Yet, ICC 12.0.1 and Clang 3.4 both pass the test, because: - They support ‘--version’; - They define ‘__GNUC__’, which defeats Autoconf’s ‘_AC_LANG_COMPILER_GNU’. - They support ‘-print-file-name’, and have ‘-print-file-name=plugin’ return GCC’s (!) plug-in header directory. To that end, ICC simply runs ‘gcc -print-file-name=plugin’, while Clang appears to be doing some guesswork. It turns out that ICC manages to build a working GCC plug-in, so after all, it may be “entitled” to define ‘__GNUC__’, in a broad sense. Conversely, Clang doesn’t support several GNU extensions, such as nested functions, so it quickly fails to compile code. Based on that, I modified my feature test like this: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=5169&r2=5203 I don’t see what can be done on “our” side (perhaps Autoconf’s feature test could be strengthened, but how?), but I wanted to document this state of affairs. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
Hi Ducan, Duncan Sands skribis: >> A number of compilers claim to be GCC, without actually being GCC. This >> has come to a point where they can hardly be distinguished–until one >> actually tries to use them. > > this suggests that you shouldn't be testing for GCC, and instead should be > testing for support for particular features. For example, to know if nested > functions are supported you would have your configure script compile a mini > program that uses nested functions. Yes. The macro I posted is a feature test: it tests for plug-in header availability, and the availability of several GCC internal types and declarations. When I noticed that Clang doesn’t support nested functions, I added that to the test: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=5169&r2=5203 Yet, I can’t reasonably add a feature test for each GNU extension that GCC’s headers or my own code use. Maybe tomorrow Clang will support nested functions, while still lacking support for some other extension that’s needed. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
Hi Ludo, I didn't really get it. Why do you want to know whether the compiler is GCC or not? Presumably because you have several versions of your code, one version using GCC feature XYZ and the other not using XYZ. If so, the logically correct (but maybe impractical) approach is to test if the compiler supports XYZ, and switch between the two code versions depending on that. For example if XYZ is "nested functions", do you have a version of your code that uses nested functions and another that does not? If you don't have a version that works with compilers like clang that don't support nested functions, then why bother testing for nested function support? You will discover the lack of nested function support when your code fails to compile. Ciao, Duncan. On 19/01/12 15:39, Ludovic Courtès wrote: Hi Ducan, Duncan Sands skribis: A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them. this suggests that you shouldn't be testing for GCC, and instead should be testing for support for particular features. For example, to know if nested functions are supported you would have your configure script compile a mini program that uses nested functions. Yes. The macro I posted is a feature test: it tests for plug-in header availability, and the availability of several GCC internal types and declarations. When I noticed that Clang doesn’t support nested functions, I added that to the test: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=5169&r2=5203 Yet, I can’t reasonably add a feature test for each GNU extension that GCC’s headers or my own code use. Maybe tomorrow Clang will support nested functions, while still lacking support for some other extension that’s needed. Thanks, Ludo’.
GNU Tools Cauldron 2012 - Call for Abstracts and Participation
REMINDERS:
1- If you are thinking of preparing a presentation ahead of
time, please let us know before 31/Jan. You do not need to
prepare a detailed write-up. We will also be voting on
discussion topics just ahead of the conference, like we did
at the last one.
2- Please REGISTER EARLY! (it does not matter if you
don't yet know whether you will be presenting).
We are trying to avoid charging for admission, but we need to
know how many will attend well in advance so we can work out
the costs.
==
GNU Tools Cauldron 2012
http://gcc.gnu.org/wiki/cauldron2012
Call for Abstracts and Participation
July 9-11, 2012
Charles University, Prague, Czech Republic
Co-organized by
UIUK (Computer Science Institute, Charles University)
CE-ITI (Institute for Theoretical Computer Science)
Google
Current Sponsors
AdaCore
Google
IBM
Abstract submission deadline: 31 January 2012
==
We are pleased to announce another gathering of GNU tools
developers. The basic format of this meeting will be similar to
the last one at the Google offices in London
(http://gcc.gnu.org/wiki/GCCGathering2011).
The purpose of this workshop is to gather all GNU tools
developers, discuss current/future work, coordinate efforts,
exchange reports on ongoing efforts, discuss development plans
for the next 12 months, developer tutorials and any other related
discussions.
Initially, we are thinking of meeting for 2 to 3 days. This time
we will meet at the Lesser Town Campus of Charles University in
Prague (Malostranske Namesti 25, Prague, Czech Republic) in July
2012. We are still in the planning process, so these dates are
tentative.
We are inviting every developer working in the GNU toolchain:
GCC, GDB, binutils, runtimes, etc. The basic format of the
meeting will be similar, but in addition to discussion topics
selected at the conference, we are looking for advance
submissions.
If you have a topic that you would like to present, please submit
an abstract describing what you plan to present. We are
accepting three types of submissions:
- Prepared presentations: demos, project reports, etc.
- BoFs: coordination meetings with other developers.
- Tutorials for developers. No user tutorials, please.
Note that we will not be doing in-depth reviews of the
presentations. Mainly we are looking for applicability and to
decide scheduling. There will be time at the conference to add
other topics of discussion, similarly to what we did at the
London meeting.
To register your abstract, send e-mail to
tools-cauldron-ad...@googlegroups.com.
Your submission should contain the following information:
Title:
Authors:
Abstract:
If you intend to participate, but not necessarily present, please
let us know as well. Send a message to
tools-cauldron-ad...@googlegroups.com stating your intent to
participate.
Re: Getting rid of duplicate .debug_ranges
On Sun, 2012-01-15 at 19:42 +0100, Mark Wielaard wrote: > I noticed that when you generate dwarf for an inlined function it often > comes with duplicate range lists for both the DW_TAG_inlined_subroutine > and the child DW_TAG_lexical_block DIE. I filed a bug report for it with some additional statistics: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51902 > I had hoped I could detect and then reduce the duplication of the range > lists in this case with the attached patch where I just check that the > basic block numbers for the ranges are the same as the ranges of its > context DIE. But that doesn't actually work since by looking at the > generated assembly the basic block asm labels are in the same place, > the block numbers are actually different (and so there are actually > two differently named/numbered labels generated at the same place). > [...] > Is there a way to detect that basic blocks have the same range even > though they have different block numbers? Or am I not looking/thinking > about this issue correctly? I don't mind trying to fix this myself, but would need some help. As a start could I trick someone into looking at my patch and saying something like: "yeah, looks sane, take a look at BLOCK_FOOBAR_RANGE_NUM to get at the info you actually want" or "sorry, you would need to do that at a totally different level, the range/basic block chain information is just lost at dwarf2out time". Thanks, Mark
Re: Dealing with compilers that pretend to be GCC
On 01/19/12 06:24, Ludovic Courtès wrote: > I don’t see what can be done on “our” side (perhaps Autoconf’s feature > test could be strengthened, but how?) Which feature test would that be? I certainly understand the problem, and have run into issues where clang fools 'configure' into thinking a GCC feature is present when it isn't, but testing whether a compiler is GCC is not really the Autoconf Way. A 'configure' script is supposed to check for behavior, not identity. If the compiler supports the features needed, then generally speaking a 'configure' script shouldn't care whether the compiler is truly GCC.
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
On 1/19/2012 9:27 AM, willus.com wrote: On 1/19/2012 2:59 AM, Richard Guenther wrote: On Thu, Jan 19, 2012 at 7:37 AM, Marc Glisse wrote: On Wed, 18 Jan 2012, willus.com wrote: For those who might be interested, I've recently benchmarked gcc 4.6.3 (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: http://willus.com/ccomp_benchmark2.shtml http://en.wikipedia.org/wiki/Microsoft_Windows_SDK#64-bit_development For the math functions, this is normally more a libc feature, so you might get very different results on different OS. Then again, by using -ffast-math, you allow the math functions to return any random value, so I can think of ways to make it even faster ;-) Also for math functions you can simply substitute the Intel compilers one (GCC uses the Microsoft ones) by linking against libimf. You can also make use of their vectorized variants from GCC by specifying -mveclibabi=svml and link against libimf (the GCC autovectorizer will then use the routines from the Intel compiler math library). That makes a huge difference for code using functions from math.h. Richard. -- Marc Glisse Thank you both for the tips. Are you certain that with the flags I used Intel doesn't completely in-line the math2.h functions at the compile stage? gcc? I take it to use libimf.a (legally) I would have to purchase the Intel compiler? In-line math functions, beyond what gcc does automatically (sqrt...) are possible only with x87 code; those aren't vectorizable nor remarkably fast, although quality can be made good (with care). As Richard said, the icc svml library is the one supporting the fast vector math functions. There is also an arch-consistency version of svml (different internal function names) which is not as fast but may give more accurate results or avoid platform-dependent bugs. Yes, the Intel library license makes restrictions on usage: http://software.intel.com/en-us/articles/faq-intel-parallel-composer-redistributable-package/?wapkw=%28redistributable+license%29 You might use it for personal purposes under terms of this linux license: http://software.intel.com/en-us/articles/Non-Commercial-license/?wapkw=%28non-commercial+license%29 It isn't supported in the gcc context. Needless to say, I don't speak for my employer. -- Tim Prince
Re: Dealing with compilers that pretend to be GCC
Hi Paul, Paul Eggert skribis: > A 'configure' script is supposed to check for behavior, not identity. > If the compiler supports the features needed, then generally speaking > a 'configure' script shouldn't care whether the compiler is truly GCC. Right. But how would you write feature tests that would check (1) whether the GNU C language is supported, and (2) whether GCC plug-ins are supported? That’s the problem I’m trying to solve. Thanks, Ludo’.
Re: Dealing with compilers that pretend to be GCC
Duncan Sands skribis: > Why do you want to know whether the compiler > is GCC or not? Because I’m writing a plug-in for GCC. Ludo’.
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
libacml from AMD is also a good candidate to try: http://www.ualberta.ca/AICT/RESEARCH/LinuxClusters/doc/acml350/Linking_002fWindows.html David On Thu, Jan 19, 2012 at 2:59 AM, Richard Guenther wrote: > On Thu, Jan 19, 2012 at 7:37 AM, Marc Glisse wrote: >> On Wed, 18 Jan 2012, willus.com wrote: >> >>> For those who might be interested, I've recently benchmarked gcc 4.6.3 >>> (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: >>> >>> http://willus.com/ccomp_benchmark2.shtml >> >> >> http://en.wikipedia.org/wiki/Microsoft_Windows_SDK#64-bit_development >> >> For the math functions, this is normally more a libc feature, so you might >> get very different results on different OS. Then again, by using >> -ffast-math, you allow the math functions to return any random value, so I >> can think of ways to make it even faster ;-) > > Also for math functions you can simply substitute the Intel compilers one > (GCC uses the Microsoft ones) by linking against libimf. You can also make > use of their vectorized variants from GCC by specifying -mveclibabi=svml > and link against libimf (the GCC autovectorizer will then use the routines > from the Intel compiler math library). That makes a huge difference for > code using functions from math.h. > > Richard. > >> -- >> Marc Glisse
RE: Dealing with compilers that pretend to be GCC
Write a test that checks for the existence of that machinery. I agree with the earlier comments. Checking version strings or program names is the wrong way, because you're essentially saying "if it is X then I know it can do Y" rather than directly asking the question "can it do Y". The issue with "if it is X then..." is that a rule of that form is fragile. Even if it is correct today -- which is unlikely -- it WILL be wrong tomorrow. What matters for your purposes is "can it do Y" -- does it (1) support the language features you need, and (2) does it support the GCC plugin mechanism. If the answer to both questions is yes, then your code should work, and it doesn't matter one bit whether the compiler calls itself GCC or FOOCC. paul -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Ludovic Courtès Sent: Thursday, January 19, 2012 11:52 AM To: Paul Eggert Cc: gcc@gcc.gnu.org; bug-autoc...@gnu.org Subject: Re: Dealing with compilers that pretend to be GCC Hi Paul, Paul Eggert skribis: > A 'configure' script is supposed to check for behavior, not identity. > If the compiler supports the features needed, then generally speaking > a 'configure' script shouldn't care whether the compiler is truly GCC. Right. But how would you write feature tests that would check (1) whether the GNU C language is supported, and (2) whether GCC plug-ins are supported? That’s the problem I’m trying to solve. Thanks, Ludo’.
Re: readonly register
BELBACHIR Selim writes: > In fact my final purpose is to replace $INP by a register bank in order to be > able to read several inputs using pipelined instructions (and instruction > scheduler). The fixed reg solution will prevent me from doing this. Is there > another way to prevent the use of some registers during the reload pass > without turning them into fixed register ? I can't think of any simple way offhand. My experience is that in extreme cases the register allocator will try to use every available register. It sounds like you want the allocator to manage the register bank, but you don't want it to use registers from that bank for outputs. The allocator doesn't really work that way. Perhaps there is a way that I don't know about. Ian > -Message d'origine- > De : Ian Lance Taylor [mailto:i...@google.com] > Envoyé : jeudi 19 janvier 2012 00:17 > À : BELBACHIR Selim > Cc : gcc@gcc.gnu.org > Objet : Re: readonly register > > BELBACHIR Selim writes: > >> I'm trying to support an 'in' instruction which reads a value on a >> peripheral and writes it into a $INP register. >> The $INP register can be used in almost every insn as input operand (add, >> sub, mul ...). >> I defined a builting to access the 'in' instruction. >> >> How should I express to gcc that the $INP register can only be 'read' and >> must never be written? >> >> For the moment, I encounter a problem during IRA pass where some of my >> 'classic' registers are reloaded into $INP (apparently because I have no >> register left). > > If you have a builtin to access the value, then you should be able to > make it a fixed register. The register allocator will never try to > allocate a fixed register. > > Ian
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
Nice work! The only think is that you didn't enable WPO/LTCG on VC++ builds, so that test is a little skewed... On 2012/1/18 20:35, willus.com wrote: Hello, For those who might be interested, I've recently benchmarked gcc 4.6.3 (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: http://willus.com/ccomp_benchmark2.shtml willus.com
Re: Hashing regs and subregs
"Paulo J. Matos" writes: > I am developing a new pass and looking for suggestions on the best way > to record in a data structure which regs and subregs I have seen and > which mode they are in through the insn chain so I know if I find > duplicates. > > Any suggestions on the best way to do this? > Are there any rtx hashes already implemented somewhere? Note that pseudo-regs always have the same mode. Hard regs and subregs do not. There are lots of ways to record regs and subregs. There is nothing very wrong with allocate a VEC of size max_reg_num (). Plenty of passes do that. If you really want a hash table, you can use iterative_hash_rtx to get the hash code. Just pass 0 as the hash argument. Ian
Interface Method Table
For a Go program being compiled in gcc, from the middle end, is there a way to figure-out which routines make up the interface-method-table? I could check the mangled name of the method table, but is there another way to deduce what methods compose it from the middle-end? Thanks! -Matt
gcc-4.5-20120119 is now available
Snapshot gcc-4.5-20120119 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120119/ 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 183314 You'll find: gcc-4.5-20120119.tar.bz2 Complete GCC MD5=a35cd32ec166b260f8a6bf6ac3ff8a3e SHA1=ed06940263a78ec5e940a28adad45b1838a66d35 Diffs from 4.5-20120112 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.
Re: Dealing with compilers that pretend to be GCC
On 19/01/2012 16:51, Ludovic Courtès wrote: > Right. But how would you write feature tests that would check (1) > whether the GNU C language is supported, Try and compile a conftest that uses it. If you wanted a possibly over-engineered solution, write one conftest for each feature of GNU C that you might want to use; otherwise maybe just write one conftest that uses as many different features as you can think of. > and (2) whether GCC plug-ins are supported? Write a conftest that actually compiles a minimal basic gcc plugin, attempts to invoke the compiler with it, and looks for it to output "Hello world" or whatever. That could be tricky because I guess you won't be able to use libtool at configure time. Maybe you could just try invoking the compiler with the right options to load the lto-plugin, check that that works, then invoke it with a -plugin option pointing to a non-existent file name and make sure that that fails, just to be sure that the compiler is actually using the option flag and not just ignoring it. cheers, DaveK
Re: trouble emilinating redundant compares
On 17/01/2012 21:16, Paul S wrote: > For example the i386 seems to use predicates and constraints of the form > <*_operand> and for the reload versions of these instructions - > and I haven't been able to find definitions of these or a mention in > gcc_internals.pdf of any special meaning assigned to the <> notation. See http://gcc.gnu.org/onlinedocs/gccint/Substitutions.html, and take a look for the define_[code/mode]_[attr/iterator] definitions around line ~650ish of i386.md cheers, DaveK
Re: Dealing with compilers that pretend to be GCC
On 2012-01-19 15:58:22 +0100, Duncan Sands wrote:
> Hi Ludo, I didn't really get it. Why do you want to know whether the compiler
> is GCC or not? Presumably because you have several versions of your code,
> one version using GCC feature XYZ and the other not using XYZ. If so, the
> logically correct (but maybe impractical) approach is to test if the compiler
> supports XYZ, and switch between the two code versions depending on that.
> For example if XYZ is "nested functions", do you have a version of your code
> that uses nested functions and another that does not? If you don't have a
> version that works with compilers like clang that don't support nested
> functions, then why bother testing for nested function support? You will
> discover the lack of nested function support when your code fails to compile.
I don't know whether Ludo can use this approach, but it not possible
when providing a header file for some library (e.g. MPFR's mpfr.h).
For ICC, one can test __ICC. For instance, here's what we have in mpfr.h
(for the use of __builtin_constant_p and __extension__ ({ ... })):
#if defined (__GNUC__) && !defined(__ICC) && !defined(__cplusplus)
--
Vincent Lefèvre - Web:
about hosting the gcc.
Dear Sir/madam, You wish to host a new mirror site, in my area. Below mention is my personal detail. Name: Santosh Sharma poudel City: kathmandu. Country: Nepal. Looking forward for your positive responce Regards, Santosh Sharma Poudel
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
On 1/18/2012 10:37 PM, Marc Glisse wrote: On Wed, 18 Jan 2012, willus.com wrote: For those who might be interested, I've recently benchmarked gcc 4.6.3 (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: http://willus.com/ccomp_benchmark2.shtml http://en.wikipedia.org/wiki/Microsoft_Windows_SDK#64-bit_development For the math functions, this is normally more a libc feature, so you might get very different results on different OS. Then again, by using -ffast-math, you allow the math functions to return any random value, so I can think of ways to make it even faster ;-) I use -ffast-math all the time and have always gotten virtually identical results to when I turn it off. The speed difference is important for me.
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
On 1/19/2012 6:29 AM, Richard Guenther wrote: On Thu, Jan 19, 2012 at 3:27 PM, willus.com wrote: On 1/19/2012 2:59 AM, Richard Guenther wrote: On Thu, Jan 19, 2012 at 7:37 AM, Marc Glissewrote: On Wed, 18 Jan 2012, willus.com wrote: For those who might be interested, I've recently benchmarked gcc 4.6.3 (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: http://willus.com/ccomp_benchmark2.shtml http://en.wikipedia.org/wiki/Microsoft_Windows_SDK#64-bit_development For the math functions, this is normally more a libc feature, so you might get very different results on different OS. Then again, by using -ffast-math, you allow the math functions to return any random value, so I can think of ways to make it even faster ;-) Also for math functions you can simply substitute the Intel compilers one (GCC uses the Microsoft ones) by linking against libimf. You can also make use of their vectorized variants from GCC by specifying -mveclibabi=svml and link against libimf (the GCC autovectorizer will then use the routines from the Intel compiler math library). That makes a huge difference for code using functions from math.h. Richard. -- Marc Glisse Thank you both for the tips. Are you certain that with the flags I used Intel doesn't completely in-line the math2.h functions at the compile stage? Yes. Intel merely comes with its own (optimized) math library while GCC has to rely on the operating system one. Wouldn't it be possible to in-line the standard C math functions in math.h, though, if the correct compiler flags were set? I realize this could be a big task and would potentially have a lot of dependencies on the CPU flag settings, but is it at least conceivable? Or is it highly undesirable for some reason? (I almost don't see how Intel could be so fast on some of those functions without in-lining.) Alternately, is anybody developing an open-source, x86-based or x64-based fast math library (just for standard C math functions--I don't need vector/array/BLAS/etc.) that auto-detects and takes advantage of modern CPU capabilities?
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
On 1/19/2012 9:24 PM, willus.com wrote: On 1/18/2012 10:37 PM, Marc Glisse wrote: On Wed, 18 Jan 2012, willus.com wrote: For those who might be interested, I've recently benchmarked gcc 4.6.3 (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here: http://willus.com/ccomp_benchmark2.shtml http://en.wikipedia.org/wiki/Microsoft_Windows_SDK#64-bit_development For the math functions, this is normally more a libc feature, so you might get very different results on different OS. Then again, by using -ffast-math, you allow the math functions to return any random value, so I can think of ways to make it even faster ;-) I use -ffast-math all the time and have always gotten virtually identical results to when I turn it off. The speed difference is important for me. The default for the Intel compiler is more aggressive than gcc -ffast-math -fno-cx-limited-range, as long as you don't use one of the old buggy mathinline.h header files. For a fair comparison, you need detailed attention to comparable options. If you don't set gcc -ffast-math, you will want icc -fp-model-source. It's good to have in mind what you want from the more aggressive options, e.g. auto-vectorization of sum reduction. If you do want gcc -fcx-limited range, icc spells it -complex-limited-range. -- Tim Prince
Re: C Compiler benchmark: gcc 4.6.3 vs. Intel v11 and others
"willus.com" writes: >> For the math functions, this is normally more a libc feature, so you >> might get very different results on different OS. Then again, by using >> -ffast-math, you allow the math functions to return any random value, >> so I can think of ways to make it even faster ;-) > > I use -ffast-math all the time and have always gotten virtually > identical results to when I turn it off. The speed difference is > important for me. Also, of course, "-ffast-math" is really shorthand for a bunch of more detailed options; which are OK and which are not is often very application-dependent. One can easily fine-tune the result by either using the more detailed options instead of -ffast-math, or perhaps by specifying -ffast-math and then turning _off_ (with -fno-xxx) anything that's too risky -Miles -- `There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.'
