Re: [AArch64] Usage of FP regs whe only GP regs are allowed
On 04/08/14 23:34, Evandro Menezes wrote: I noticed that when -mgeneral-regs-only FP registers are still used by the LRA for spilling. Though in rare cases I saw an ICE because of it, even when it works it seems to me that the compiler should follow the desires of its user. If you've noticed that mgeneral-regs-only causes the use of FP registers that is a bug and needs to be fixed. Please file a proper bug report with an actual testcase that can be of use for someone to recreate the problem. I filed PR 62014 and posted there a patch to address this issue and restrict the LRA from using FP registers if the user so desires. Please send patches to the mailing list. I think however in this case you are papering over the problem as explained in the PR. regards Ramana
Re: writing patterns
On Mon, Aug 4, 2014 at 4:44 PM, Prathamesh Kulkarni wrote: > On Mon, Aug 4, 2014 at 2:59 PM, Richard Biener > wrote: >> On Mon, Aug 4, 2014 at 12:16 AM, Prathamesh Kulkarni >> wrote: >>> On Thu, Jul 31, 2014 at 2:49 PM, Prathamesh Kulkarni >>> wrote: On Thu, Jul 31, 2014 at 2:44 PM, Richard Biener wrote: > On Thu, Jul 31, 2014 at 11:09 AM, Prathamesh Kulkarni > wrote: >> On Thu, Jul 31, 2014 at 2:15 PM, Richard Biener >> wrote: >>> On Thu, Jul 31, 2014 at 7:41 AM, Prathamesh Kulkarni >>> wrote: On Wed, Jul 30, 2014 at 11:49 PM, Prathamesh Kulkarni wrote: > On Wed, Jul 30, 2014 at 4:49 PM, Richard Biener > wrote: >> On Wed, Jul 30, 2014 at 1:11 PM, Richard Biener >> wrote: >>> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >>> wrote: Hi, Sorry to ask a stupid question, but I am having issues writing patterns involving casts. I am trying to write patterns from simplify_rotate. Could you show me how to write a patterns that involve casts ? for eg: ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B T -> some unsigned type with bitsize B, and some type T2 wider than T. How to express this in the pattern ? >>> >>> [copying gcc@ because of the syntax stuff] >>> >>> for example with (leaving captures as the appear in the pattern >>> above) >>> >>> (match_and_simplify >>>(plus (convert@2 (lshift (convert@0 X) CNT1)) >>>(convert (rshift (convert@1 X) CNT2))) >>> /* Types T2 have to match */ >>>(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) >>> /* Type T should be unsigned. */ >>>&& TYPE_UNSIGNED (TREE_TYPE (@2)) >>>/* T2 should be wider than T. */ >>>&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION >>> (TREE_TYPE (@2)) >>>/* CNT1 + CNT2 == B */ >>>&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >>>wi::add (CNT1, CNT2 >>>(lrotate CNT1)) >> >> Note that this will _explicitely_ require a conversion. That is, if >> T == T2 >> it won't match because the conversion to T will not be there, nor if >> X >> is already of type T2. >> >> Which means that we want to match multiple variants of this >> (with conversions in place or not). Hmm. Maybe with extending >> 'for' like >> >> (for cvt1 in convert * >> (fot cvt2 in convert * >> (plus@2 (cvt1 (lshift@0 (cvt2 X) CNT1)) >> (cvt1 (rshift@1 (cvt2 X) CNT2))) >> ... >> >> adding an "empty" operator to the list of operators to substitute >> for cvt1 >> and allowing nested for. The "empty" operator would necessarily be >> unary and be just un-wrapped. > Would it be better to have syntax (say using ?) for denoting that an > operator is optional ? > operator should be unary, and it's operand must be an expression. > > so the pattern becomes sth like: > (plus@2 (convert? (lshift@0 (convert? X) CNT1)) > (convert? (rshift@1 (convert? X) CNT2))) > Let me rephrase it. An operator can be marked optional, if a) it's unary b) if in outermost-expr, the operand must be an expression I want to reject case like: (negate? @0) (op? operand) generates code : match (op) match (operand) and once without op match (operand) Implementation-wise I think, we could duplicate the AST, like we do for "for pattern". Would that be okay ? >>> >>> I thought of something similar but how exactly would you do the >>> duplication in the above example? The point is that we know >>> that the conversions will exist in pairs, that is, either >>> the two outer and no inner or no outer and both inner or >>> both outer and both inner. You can express that with the >>> nested for - with just a '?' you can't do that. Of course you could >>> do sth like >>> >>> (plus@2 (convert?1 (lshift@0 (convert?2 X) CNT1)) >>> (convert?1 (rshift@1 (convert?2 X) CNT2))) >>> >>> that is, add an index to ?s and tie them together. We want to >>> avoid generating useless patterns - in this case 4 are sufficient >>> but if we generate all possible combinations we'd have an additional >>> 12 useless patterns. >> Ah yes, d
Warning about variable optimized away?
Hello,
it it possible to get a kind of diagnostics if the variable
is totally optimized away? For example, in:
void foo (struct some_type *obj) {
... some code where 'obj' is not used ...
bar (obj->some_member);
... some code where 'obj' is not used again ...
baz (obj->some_member);
}
'obj' is likely to be optimized away so only 'obj->some_member' really
exists (in a register or stack location). Getting diagnostics
or preserving 'obj' may be important if there is a GC which scans
C stack and registers conservatively - if there is no direct reference
to 'obj', it's likely to be reclaimed and so 'obj->some_member'
becomes garbage.
Dmitry
Re: Warning about variable optimized away?
On Tue, Aug 5, 2014 at 4:54 AM, Dmitry Antipov wrote:
>
> it it possible to get a kind of diagnostics if the variable
> is totally optimized away? For example, in:
>
> void foo (struct some_type *obj) {
> ... some code where 'obj' is not used ...
> bar (obj->some_member);
> ... some code where 'obj' is not used again ...
> baz (obj->some_member);
> }
>
> 'obj' is likely to be optimized away so only 'obj->some_member' really
> exists (in a register or stack location). Getting diagnostics
> or preserving 'obj' may be important if there is a GC which scans
> C stack and registers conservatively - if there is no direct reference
> to 'obj', it's likely to be reclaimed and so 'obj->some_member'
> becomes garbage.
This question would be more appropriate on gcc-h...@gcc.gnu.org. The
gcc@gcc.gnu.org list is for discussion about the development of GCC.
Please take any followups to gcc-help. Thanks.
There are no diagnostics for a variable being optimized away. That is
a normal occurrence.
If obj->some_member is loaded into a register, then it doesn't matter
whether obj is collected. If obj->some_member is not loaded into a
register, then there must be some pointer into obj, and a conservative
GC will not collect the memory.
Ian
Re: [GNU Tools Cauldron 2014] Unifying GENERIC and GIMPLE folding with pattern description
On Mon, Aug 4, 2014 at 11:41 PM, Prathamesh Kulkarni wrote: > Hi, > Please find my note attached for the presentation on "Unifying GENERIC > and GIMPLE folding with pattern description" at Cauldron. > I would be grateful if you would review it for me. Looks good to me. Richard. > Thanks, > Prathamesh.
Trying to develop new frontend
Hello,
i am trying to develop a GCC frontend using flex and bison as lexer/parser.
i've read several documentation (the list below and also the gccint.info)
* https://github.com/rabishah/Mini-C-Compiler-using-Flex-And-Yacc/
* http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html
* https://gcc.gnu.org/wiki/WritingANewFrontEnd
* https://gcc.gnu.org/ml/gcc-patches/2006-06/msg00648.html
* https://gcc.gnu.org/wiki/FrontEnd/skeleton
* http://blog.lxgcc.net/wp-content/uploads/2011/03/GCC_frontend.pdf
* http://cobolforgcc.sourceforge.net/cobol_14.html#SEC96
* https://gcc.gnu.org/onlinedocs/gccint/Parsing-pass.html#Parsing-pass
but still having some problems to make it work.
the code is on github:
https://github.com/danielneis/gcc-neis-frontend
the project compiles and generates my compiler "neis1". it is a valid
elf and i can run it with --help and it shows me the help.
I am testing it with a simple .c file like this:
int main() {
return 0;
}
~/bin$ ./gcc -x neis /home/neis/test.c
/usr/lib/x86_64-linux-gnu/crt1.o: In function `_start':
/home/aurel32/glibc/glibc-2.19/csu/../sysdeps/x86_64/start.S:118:
undefined reference to `main'
collect2: error: ld returned 1 exit status
I think I may be missing some part of code generation with generic,
but could not find any references...
Any thoughts?
Kind regards,
Daniel
[GNU Tools Cauldron 2014] GCC Re-architecture BOF
Hi, I have written notes on "GCC re-architecture BOF" presented at the Cauldron. I would be grateful if you would review it for me. GCC re-architecture BOF Author: Andrew MacLeod This project is follow-up to GNU Tools Cauldron 2013 GCC re-architecture BOF, focused on better modularization of the code-base. Project Goals: 1) Controlled border between the front-end and middle-end Identify border for separation of front-end from back-end (where front-end hand overs GIMPLE to back-end). All components that interact across this border should have a well defined API. Implementation Strategy: a) Header file flattening: - No header file builds any other header file - .h has prototypes only for .c - analyze dependencies and rebuild proper component headers - move functions to appropriate places. b) Deforestation - replace tree with C++ wrapper class - doable but lot of churn with limited gain c) Types: - integrate with LTO type tables - push back to gimplification - LTO types become gimple types d) Decls - integrate with LTO symbol table - push back to gimplification - LTO symbols become GIMPLE symbols 2) Formalization of GIMPLE Second goal of this project is to formalize GIMPLE, and make it independent from the front-end. Following plan is sketched for GIMPLE formalization: - Removal of trees from GIMPLE and RTL - Creating debug API - Removing front-end hooks Formalizing GIMPLE shall have many advantages: - Easier to maintain code - Enhanced unit testing - Solves debug info issue for LTO - Textual streaming of LTO - Well defined interface for FE to generate IL c) Front-end IL generation more closer to source The third goal is to retain front-end information closer to source. This will help for easier debugging and better integration of source analysis tools with GCC. Required changes in FE: removal of folding and micro-optimizations. Thanks, Prathamesh
RE: Build failure for sparc-sun-solaris2.10
> Hi Art,
Hello.
>> Could be, see above. Apart from that, I wonder why you insist on using
>> GNU ld on Solaris. install.texi strongly suggests to use the Solaris
>> linker instead, and I stand by that advise.
>
>> A couple of comments on those configure options: avoid everything not
>> strictly necessary and stay with the defaults.
> { ... snip build error ... }
> it seems something is very wrong here. The use of -M
> .../libgcc-unwind.map indicates that gcc configure thinks that the
> Solaris ld (/usr/ccs/bin/ld) is in ise, while libtool is invoking the
> linker with -soname, which only happens for GNU ld.
> How exactly did you configure gcc to use the system linker? If all else
> fails, I suggest to use --without-gnu-ld --with-ld=/usr/ccs/bin/ld to
> make certain the right one is in use. One possible cause of your
> problems could be if you have GNU ld in your path called ld. I've never
> done that (I always call it gld-), but the above configure
> options should help if you are unable to get rid of such an ld.
I tried the '--without-gnu-ld --with-ld=/usr/ccs/bin/ld' configure options
and my build failed again as my GNU 'ld' binary was again being found. So
the next step was to rename my installed GNU 'ld' to 'ld-2.24' and adjust
my $PATH so that the directory where it was installed wouldn't be found, and
rebuild. I'm happy to report this build was a success:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/sparc-sun-solaris2.10/4.10.0/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: /export/home/arth/src/gcc.git/configure
--prefix=/export/home/arth/local --enable-languages=c,c++,objc --disable-nls
--with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local
--with-mpc=/export/home/arth/local --enable-checking=release
--with-as=/export/home/arth/local/bin/as --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
Thread model: posix
gcc version 4.10.0 20140804 (experimental) [master revision
0549e5a:2217af7:347a47cbf5f8ee0bc7e11dc97703b318d3ff259c] (GCC)
$
Thanks for your help in resolving this and maintaining the Solaris port.
Art Haas
[GNU Tools Cauldron 2014] GCC and LLVM collaboration
Hi, I have written notes on "GCC and LLVM collaboration BOF" presented at the Cauldron. I would be grateful if you would review it for me. GCC and LLVM Collaboration Author: Renato Golin Motivation behind collaboration is to address problems that are intrinsic to the compilation infrastructure, which cannot be included in any standard (language, extension or machine-specific), and have common solutions for at least GCC and LLVM. The BOF focuses only on technical aspects, and as such licensing issues, personal grudges and performance are off-topic. Collaboration shall help to protect users from any potential disagreements that would take place among different implementations. It aims for standardization regarding: - compiler flags - attributes - extensions - builtins - ASM - Linker API An implementation need not support all standard set of features (for instance -Wfoo warning), emitting a "not supported" diagnostic for that feature would be fine. Common projects that may be collaborated on - binutils - glibc - sanitizers Sanitizers are a collaboration success story. Thank-you, Prathamesh
Re: Trying to develop new frontend
On 5 August 2014 15:17, Daniel Neis wrote:
> Hello,
>
> i am trying to develop a GCC frontend using flex and bison as lexer/parser.
>
> i've read several documentation (the list below and also the gccint.info)
>
> * https://github.com/rabishah/Mini-C-Compiler-using-Flex-And-Yacc/
> * http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html
> * https://gcc.gnu.org/wiki/WritingANewFrontEnd
> * https://gcc.gnu.org/ml/gcc-patches/2006-06/msg00648.html
> * https://gcc.gnu.org/wiki/FrontEnd/skeleton
> * http://blog.lxgcc.net/wp-content/uploads/2011/03/GCC_frontend.pdf
> * http://cobolforgcc.sourceforge.net/cobol_14.html#SEC96
> * https://gcc.gnu.org/onlinedocs/gccint/Parsing-pass.html#Parsing-pass
>
> but still having some problems to make it work.
>
> the code is on github:
>
> https://github.com/danielneis/gcc-neis-frontend
>
> the project compiles and generates my compiler "neis1". it is a valid
> elf and i can run it with --help and it shows me the help.
>
> I am testing it with a simple .c file like this:
>
> int main() {
> return 0;
> }
>
> ~/bin$ ./gcc -x neis /home/neis/test.c
> /usr/lib/x86_64-linux-gnu/crt1.o: In function `_start':
> /home/aurel32/glibc/glibc-2.19/csu/../sysdeps/x86_64/start.S:118:
> undefined reference to `main'
> collect2: error: ld returned 1 exit status
>
>
> I think I may be missing some part of code generation with generic,
> but could not find any references...
>
> Any thoughts?
>
I couldn't see any reference to cgraph_finalize_function nor
finalize_compilation_unit. So it looks like you are not sending any
code to the backend to be compiled.
This is a nice point of reference for a skeleton front-end.
https://github.com/giuseppe/gccbrainfuck
Regards
Iain
Re: [GNU Tools Cauldron 2014] GCC and LLVM collaboration
On 5 August 2014 16:36, Prathamesh Kulkarni wrote: > Hi, >I have written notes on "GCC and LLVM collaboration BOF" > presented at the Cauldron. I would be grateful if you would > review it for me. Hi Prathamesh, Sounds about right. Other reviews, FYI: http://llvmweekly.org/issue/29 http://article.gmane.org/gmane.comp.compilers.llvm.devel/75207 cheers, --renato
Re: Reload generate invalid instruction on ppc64
On Mon, Aug 4, 2014 at 9:02 PM, Alan Modra wrote: > On Mon, Aug 04, 2014 at 05:54:04PM -0700, Carrot Wei wrote: >> Another problem is in the definition of insn pattern "*movdi_internal64". >> >> (define_insn "*movdi_internal64" >> [(set (match_operand:DI 0 "nonimmediate_operand" >> "=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,r,?*wg,r,?*wm") >> (match_operand:DI 1 "input_operand" >> "r,Y,r,I,L,nF,d,m,d,*h,r,0,*wg,r,*wm,r"))] >> "TARGET_POWERPC64 >>&& (gpc_reg_operand (operands[0], DImode) >>|| gpc_reg_operand (operands[1], DImode))" >> >> The predicates of this insn pattern allow the moving of an integer to >> VSX register, but there is no constraint allow this case. Can this >> cause problem in reload? > > Probably, just as you found with fprs. The underlying issue is that > the operand predicates don't match the operand constraints. What's > more, you can't make them match without breaking up the insn, or > adding a whole lot of extra alternatives. > VSX instructions can't load integer constant to vsx registers. So I will try to split this insn to see if it can fix the reload problem. thanks a lot Guozhi Wei
Missing tags in the Git mirror
Hello, Tags for the following releases are not in the Git mirror repository: * 3.3 * 3.3.1 * 3.3.5 * 3.3.6 * 4.7.4 * 4.8.3 * 4.9.1 I figure this is the place to report it? Roman.
Re: LTO and version scripts
> What version linker? In particular, do you have the fix for PR12975? It seems to work with gold and the LLVM plugin. I have added a test to make sure it stays that way: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140804/229493.html Cheers, Rafael
Re: Reload generate invalid instruction on ppc64
On Tue, Aug 05, 2014 at 01:32:00PM +0930, Alan Modra wrote: > On Mon, Aug 04, 2014 at 05:54:04PM -0700, Carrot Wei wrote: > > Another problem is in the definition of insn pattern "*movdi_internal64". > > > > (define_insn "*movdi_internal64" > > [(set (match_operand:DI 0 "nonimmediate_operand" > > "=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,r,?*wg,r,?*wm") > > (match_operand:DI 1 "input_operand" > > "r,Y,r,I,L,nF,d,m,d,*h,r,0,*wg,r,*wm,r"))] > > "TARGET_POWERPC64 > >&& (gpc_reg_operand (operands[0], DImode) > >|| gpc_reg_operand (operands[1], DImode))" > > > > The predicates of this insn pattern allow the moving of an integer to > > VSX register, but there is no constraint allow this case. Can this > > cause problem in reload? > > Probably, just as you found with fprs. The underlying issue is that > the operand predicates don't match the operand constraints. What's > more, you can't make them match without breaking up the insn, or > adding a whole lot of extra alternatives. Can you disallow this in the condition of the pattern, just like it already requires at least one of the operands to be gpc_reg_operand? Segher
Re: LTO and version scripts
On Tue, Aug 5, 2014 at 12:57 AM, Alan Modra wrote: > What version linker? In particular, do you have the fix for PR12975? The Fedora 19 version. I think it hasn't changed since then which means it is 2.23.88.0.1-13 (from the RPM version number). No idea whether that fix is included and unfortunately won't have time to try before the weekend.
