Tested on Linux-x64.
/cp
2014-12-19 Ville Voutilainen
Reject trailing return type for an operator auto().
* decl.c (grokdeclarator): Reject trailing return types for
all conversion operators, don't handle conversion operators
in the previous checks that deal with auto.
/testsu
> Jan Hubicka writes:
>
> > Hi,
> > this patch started as experiment moving hash_table_mod1 inline because it
> > shows
> > high in streaming profiles and it represents a branch-less code that is good
> > to schedule to surrounding instructions.
>
> FWIW with a good modern hash function it shou
I merged trunk revision 218884 to the gccgo branch.
Ian
There were a few cases where the Go compiler was evaluating value
multiple times when they were converted to or from interface types.
This happened when the conversion occurred in a composite literal, or
even, when implicitly converting from one interface type to another,
in a variable declaration.
On 11/19/2014 09:34 PM, Jan Hubicka wrote:
[snip]
As for timeline, I have a workshop next week and need to prepare draft for it.
So ideally I would like to work on this only after the workshop (ending
November 28). I would be also happy to help anyone interested to help (I am
just bit slow on po
On Fri, Dec 19, 2014 at 6:09 AM, Segher Boessenkool
wrote:
> On Thu, Dec 18, 2014 at 05:00:01PM +, Jiong Wang wrote:
>> On 17/12/14 15:54, Richard Biener wrote:
>> >ick. I realize we don't have SSA form on RTL but doesn't DF provide
>> >at least some help in looking up definition statements f
Vladimir Makarov wrote:
>> * lra.c (lra_update_insn_regno_info): Take account of arguments
>> via memory which could be implicit usage of pseudo regs.
>>
>
> It could be a solution but I believe the problem should be solved in
> some other way. The patch will generate a correct code bu
Vladimir Makarov wrote:
>> * lra-constraints.c (process_address_1): Try if target can split
>> displacement with targetm.legitimize_address_displacement.
>> * target.def (legitimize_address_displacement): New hook.
>> * targhooks.c (default_legitimize_address_displacement): New
Vladimir Makarov wrote:
> I don't think it will be easy to solve this problem by following reg
> pressure. I guess R0 will be in the same pressure reg class. I
> believe some hook is an adequate solution here.
>
>> --
>> * lra-constraints.c (get_equiv): Don't return memory equivalence
>>
Hi,
This patch fix the reservation pattern of cortex_a9_neon_vmov in
cortex-a9-neon.md.
Is it OK for trunk?
Regards,
Xingxing
2014-12-19 Xingxing Pan
* config/arm/cortex-a9-neon.md (cortex_a9_neon_vmov): Change
reservation
from cortex_a8_neon_dp to cortex_a9_neon_dp
Hi Jakub,
On Tue, Nov 18, 2014 at 11:36 AM, Alexey Samsonov wrote:
>
> On Mon, Nov 17, 2014 at 11:53 PM, Jakub Jelinek wrote:
> > On Mon, Nov 17, 2014 at 11:39:47PM -0800, Alexey Samsonov wrote:
> >> > That is not what I think we've agreed on and what is implemented in GCC.
> >> > -fsanitize-rec
Jan Hubicka writes:
> Hi,
> this patch started as experiment moving hash_table_mod1 inline because it
> shows
> high in streaming profiles and it represents a branch-less code that is good
> to schedule to surrounding instructions.
FWIW with a good modern hash function it shouldn't be needed to
This patch flattens tree.h and tree-core.h. This work is part of the GCC
Re-Architecture effort being led by Andrew MacLeod.
I removed the includes in tree.h and tree-core.h except for the include
of tree-core.h in tree.h.
I modified genattrtab.c, genautomata.c, genemit.c, gengtype.c,
gengty
Since generic lambdas don't seem to work properly in C++11 mode, let's
upgrade the pedwarn to an error.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6c7d0ebb35b4918be3200625ef0cbb1816ddd7e9
Author: Jason Merrill
Date: Thu Dec 18 16:56:33 2014 -0500
PR c++/64105
* parser.c
Hi,
this patch started as experiment moving hash_table_mod1 inline because it shows
high in streaming profiles and it represents a branch-less code that is good
to schedule to surrounding instructions.
While looking at hash-tab.h I however noticed that it was not updated very
well while it was move
Hi,
I had a discussion with Michael, and would like to put this patch on
hold for now till we have tree.h and rtl.h flattening
patches checked in to avoid conflicts.
Thankyou,
Prathamesh
On 16 December 2014 at 17:13, Prathamesh Kulkarni
wrote:
> Hi,
> The attached patch flattens expr.h.
> Move
On 12/18/2014 01:16 PM, Kai Tietz wrote:
Well, in general I would have assumed to be able to get alias decl of
tmpl. Wasn't able to find a simple way to get it. So, by looking into
source I found that most cases handling args > tmpl-args by using
inner_most_template_args instead. Defaulting to
in
We were just missing a case where we want to pass complain down to avoid
a hard error in SFINAE context.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 83bea8460ce8e14e5b9d1c0dc33a0d22b63b566d
Author: Jason Merrill
Date: Thu Dec 18 12:42:34 2014 -0500
PR c++/64352
* pt.c (ts
Here we were seeing errors because of template instantiation triggered
by mark_used within fold_non_dependent_expr. We don't want to
instantiate templates based on uses in other uninstantiated templates,
and we were already trying to avoid that; let's add another check to
avoid it.
Tested x8
On Thu, Dec 18, 2014 at 05:00:01PM +, Jiong Wang wrote:
> On 17/12/14 15:54, Richard Biener wrote:
> >ick. I realize we don't have SSA form on RTL but doesn't DF provide
> >at least some help in looking up definition statements for pseudos?
> >In fact we want to restrict the transform to singl
The following patch fixes a typo in usage of register_move_cost. For
most targets, the change does not matter as the cost function is
symmetric relative to args.
The patch was bootstrapped on x86-64.
Committed as rev. 218875.
2014-12-18 Vladimir Makarov
* lra-constraints.c
On Thu, 18 Dec 2014, Jakub Jelinek wrote:
> c/
> * c-typeck.c (convert_for_assignment, c_finish_return): For
> -fsanitize=float-cast-overflow casts from REAL_TYPE to integer/enum
> types also set in_late_binary_op around convert call.
> * c-convert.c (convert): For -fsaniti
On 2014-12-17 7:57 PM, Kaz Kojima wrote:
This patch is discussed in PR55212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c49
and is to avoid segfault in remove_pseudos.
In the pro
On 2014-12-17 8:00 PM, Kaz Kojima wrote:
This patch adds a target macro discussed in PR55212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c78
is to avoid bad codes on SH.
SH has very limited base+displacement addressing and it looks
t
On 2014-12-18 2:26 PM, Mike Stump wrote:
On Dec 18, 2014, at 10:42 AM, Vladimir Makarov wrote:
Thank you very much for your work on porting LRA to SH!
I’ve ported my target to LRA, and I have not found any LRA bits I needed to
change.
Thanks, Mike. When I did a few first ports, it never
2014-12-18 17:00 GMT+00:00 Jiong Wang :
ok for trunk?
gcc/
PR62173
loop-invariant.c.c (expensive_addr): New hash_table.
(need_expensive_addr_check_p): New bool.
(find_exits): Rename to "find_exists_and_reshuffle.
Support re-shuffle instruc
On 2014-12-17 7:59 PM, Kaz Kojima wrote:
This was discussed in PR55212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c55
and is to fix ICE in assign_by_spills.
In that case, rtlana
On 2014-12-17 8:00 PM, Kaz Kojima wrote:
This was discussed in PR55212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c69
and is to fix another ICEs in assign_by_spills.
This patch
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291
It is a bug in a new rematerialization subpass of LRA.
The patch was bootstrapped on x86/x86-64.
Committed as rev. 218874.
2014-12-18 Vladimir Makarov
PR rtl-optimization/64291
* lra-remat.c
The following patch fixes testsuite failures
builtin-arith-overflow-[10,11].c. In the case where
rs6000_split_logical() was being called the operands were swapped such
that the wrong operand was being complemented.
Bootstrap/tested on powerpc64-linux with no new regressions. Ok for
trunk (and
Hi Jason.
As promised, I am moving most everything out of
cxx_post_compilation_parsing_cleanups() which is the hook that will be
called after the compilation proper has run
(symtab->finalize_compilation_unit()).
Apart from the Java hidden alias support which I just asked you about,
and the
>
> 2014-12-08 Martin Liska
>
> * lto-partition.c (add_symbol_to_partition_1): New inline_summary_d
> is used.
> (undo_partition): Likewise.
> (lto_balanced_map): Likewise.
>
> gcc/ChangeLog:
>
> 2014-12-08 Martin Liska
>
> * cgraphunit.c (symbol_table::proc
>
> gcc/lto/ChangeLog:
>
> 2014-12-08 Martin Liska
>
> * lto-partition.c: Include of symbol-summary.h is added.
> * lto-symtab.c: Likewise.
> * lto.c: Likewise.
I must say I am not friend of flattening. Hope this will be resolved for 5.1
>
> gcc/ChangeLog:
>
> 2014-12-08
> 2014-12-08 Martin Liska
>
> * cgraph.h (symbol_table::allocate_cgraph_symbol): Summary UID
> is filled up.
> * symbol-summary.h: New file.
> * gengtype.c (open_base_files): Add symbol-summary.h.
> * toplev.c (general_init): Call constructor of symbol_table.
> ---
On Thu, Dec 18, 2014 at 11:22 AM, Mike Stump wrote:
> On Dec 18, 2014, at 9:43 AM, H.J. Lu wrote:
>> + arguments passed in vector registers. This can be used to
>> + optimize Linux kernel.
>
> English, to optimize _the_ Linux kernel?
Updated.
--
H.J.
---
Index: gcc-5/changes.html
On Dec 18, 2014, at 10:42 AM, Vladimir Makarov wrote:
> Thank you very much for your work on porting LRA to SH!
I’ve ported my target to LRA, and I have not found any LRA bits I needed to
change.
On Dec 18, 2014, at 9:43 AM, H.J. Lu wrote:
> + arguments passed in vector registers. This can be used to
> + optimize Linux kernel.
English, to optimize _the_ Linux kernel?
Hi Jason.
It's embarrassing that I just got to this now. I hope you don't repay
the favor and take as long responding to me :(.
On 09/12/14 08:15, Jason Merrill wrote:
On 09/11/2014 08:51 PM, Aldy Hernandez wrote:
/* Generate hidden aliases for Java. */
- if (candidates)
+ if (java_
On Thu, 2014-12-18 at 13:42 -0500, Vladimir Makarov wrote:
> Thank you very much for your work on porting LRA to SH! I know it
> is quite a challenge to do any RA work for this target.
The R0-ness (both, GP reg r0 and FP reg fr0) of the ISA taxes the
patience sometimes. Too often, I've been t
On 2014-12-17 7:56 PM, Kaz Kojima wrote:
This patch series is to make SH target use LRA and is discussed
in the PR target/55212:
[SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
I think there are issues which should be solved before defaulting
LRA on SH and the helps from t
Hi all,
here is my next try on proposing a patch for the issue in pr60255. It took me
quite some time to understand the intricacies with handling variables
associated in a select type. I think I got most of the issues fixed now:
- Added generation of _len component for each unlimited polymorphic
On 12/18/2014 10:37 AM, Rasmus Villemoes wrote:
>
> Minor thing: If it's not too late, I'd appreciate a 'Suggested-by' or
> similar mention in the kernel change log.
>
I think we can get that.
-hpa
On Thu, Dec 18 2014, "H. Peter Anvin" wrote:
> On 12/18/2014 09:43 AM, H.J. Lu wrote:
>>
>> Peter, please feel free to use my kernel patch or create a different
>> one.
>>
>
> Great, thanks!
>
Thanks for accepting this idea, and especially to H.J. for already
having done all the work.
Minor t
On Thu, Dec 18, 2014 at 07:25:03PM +0100, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 17 Dec 2014 23:26:53 +0100, I wrote:
> > Committed to gomp-4_0-branch in r218840:
> >
> > commit febcd8dfdb10fa80edff0880973d1915ca2fef74
> > Author: tschwinge
> > Date: Wed Dec 17 22:26:24 2014 +
> >
> >
Hi!
On Wed, 17 Dec 2014 23:26:53 +0100, I wrote:
> Committed to gomp-4_0-branch in r218840:
>
> commit febcd8dfdb10fa80edff0880973d1915ca2fef74
> Author: tschwinge
> Date: Wed Dec 17 22:26:24 2014 +
>
> Use include/gomp-constants.h more actively.
> diff --git gcc/tree-core.h gcc/tree
2014-12-18 18:26 GMT+01:00 Jason Merrill :
> On 12/18/2014 10:10 AM, Kai Tietz wrote:
>>
>> + if (TMPL_ARGS_DEPTH (args) > TMPL_PARMS_DEPTH (tmpl_parms))
>> +args = get_innermost_template_args
>> +(args, TMPL_PARMS_DEPTH (tmpl_parms));
>
>
> It seems unlikely to be correct to arbit
On Thu, Dec 18, 2014 at 07:00:09PM +0100, Thomas Schwinge wrote:
> OK, so there is this limit. But, I fail to understand how merely moving
> the OpenACC-only PRAGMA_*_CLAUSE_* to the end of enum pragma_omp_clause
> will help overcome that? Or have I now completely confused myself, and
> I'm not e
Hi Jakub!
On Thu, 18 Dec 2014 15:29:42 +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 02:48:32PM +0100, Thomas Schwinge wrote:
> > > Like for CILK, I'd strongly prefer if for the clauses that are
> > > specific to OpenACC only you'd use PRAGMA_OACC_CLAUSE_* instead,
> > > and put them afte
Hi,
On 12/18/2014 06:21 PM, Jason Merrill wrote:
On 12/18/2014 11:31 AM, Paolo Carlini wrote:
+ warning_sentinel s (extra_warnings);
Let's add a comment about which warning we're avoiding here. OK with
that change.
Thanks. I'm attaching what I just committed. This is a regression, I
s
On 12/18/2014 09:43 AM, H.J. Lu wrote:
>
> Peter, please feel free to use my kernel patch or create a different
> one.
>
Great, thanks!
-hpa
On Thu, Dec 18, 2014 at 06:41:18PM +0100, Ilya Verbin wrote:
> > What we're doing in OpenACC offloading testing (gomp-4_0-branch), is in
> > the libgomp.oacc-c/c.exp (etc.) file cycle through all the available
> > offloading devices, and then in there -- I think -- such options should
> > be set, t
On Thu, Dec 18, 2014 at 9:23 AM, Uros Bizjak wrote:
> On Thu, Dec 18, 2014 at 6:08 PM, H. Peter Anvin wrote:
>> On 12/18/2014 06:12 AM, Uros Bizjak wrote:
>
> # temporary until string.h is fixed
> KBUILD_CFLAGS += -ffreestanding
>
> Yes, it looks to me that new option is the w
Hi,
2014-12-18 16:27 GMT+01:00 Thomas Schwinge :
> Hi!
>
> On Thu, 30 Oct 2014 14:40:01 +0300, Ilya Verbin wrote:
>> This patch allows to run non-fallback 'make check-target-libgomp'. It
>> passes to
>> the host compiler additional -B options with the paths to the offload
>> compilers,
>> sinc
On 12/17/2014 04:23 PM, Richard Biener wrote:
On Wed, Dec 17, 2014 at 12:17 PM, Martin Liška wrote:
On 12/11/2014 01:37 PM, Richard Biener wrote:
On Wed, Dec 10, 2014 at 1:18 PM, Martin Liška wrote:
Hello.
As suggested by Richard, I split compare_operand functions to various
functions
rel
On Thu, Dec 18, 2014 at 05:18:18PM +, Kyrill Tkachov wrote:
> Ping.
> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00947.html
This patch almost certainly falls under the obvious rule:
"will the person who objects to my work the most be able to
find a fault with my fix?"
ARM hasn't stoo
On Thu, Dec 18, 2014 at 03:13:32PM -0200, Ricardo Sardano Guanciale wrote:
> Please, can somebody help me? Where do I find GCC approved/accepted patch?
>
> Is there some patch directory in repository, if is please where?
Approved patches are usually just committed to the SVN repository,
there is
On 12/18/2014 10:10 AM, Kai Tietz wrote:
+ if (TMPL_ARGS_DEPTH (args) > TMPL_PARMS_DEPTH (tmpl_parms))
+args = get_innermost_template_args
+(args, TMPL_PARMS_DEPTH (tmpl_parms));
It seems unlikely to be correct to arbitrarily strip off outer template
args. Where did the misma
On Thu, Dec 18, 2014 at 6:08 PM, H. Peter Anvin wrote:
> On 12/18/2014 06:12 AM, Uros Bizjak wrote:
# temporary until string.h is fixed
KBUILD_CFLAGS += -ffreestanding
Yes, it looks to me that new option is the way to go.
>>>
>>> Is this an OK?
>>
>> In principle, I'm OK w
On 12/18/2014 11:31 AM, Paolo Carlini wrote:
+ warning_sentinel s (extra_warnings);
Let's add a comment about which warning we're avoiding here. OK with
that change.
Jason
On Thu, Dec 18, 2014 at 9:08 AM, H. Peter Anvin wrote:
> On 12/18/2014 06:12 AM, Uros Bizjak wrote:
# temporary until string.h is fixed
KBUILD_CFLAGS += -ffreestanding
Yes, it looks to me that new option is the way to go.
>>>
>>> Is this an OK?
>>
>> In principle, I'm OK w
Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00947.html
Thanks,
Kyrill
On 10/12/14 16:50, Kyrill Tkachov wrote:
Hi all,
The company ARM is not Advanced RISC Machines anymore and anyway the ARM
architecture is distinct from the company.
This patch adjusts the documentation accordingly.
O
Please, can somebody help me? Where do I find GCC approved/accepted patch?
Is there some patch directory in repository, if is please where?
Thanks and best regards,
Ricardo
On 12/18/2014 06:12 AM, Uros Bizjak wrote:
>>>
>>> # temporary until string.h is fixed
>>> KBUILD_CFLAGS += -ffreestanding
>>>
>>> Yes, it looks to me that new option is the way to go.
>>
>> Is this an OK?
>
> In principle, I'm OK with the patch approach, but let's wait for
> eventual comments fro
On 17/12/14 15:54, Richard Biener wrote:
On Mon, Dec 15, 2014 at 4:29 PM, Jiong Wang wrote:
On 15/12/14 15:28, Jiong Wang wrote:
On 04/12/14 19:32, Jiong Wang wrote:
On 04/12/14 11:07, Richard Biener wrote:
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
wrote:
On Thu, Dec 4, 2014 at 12:
On Wed, Dec 17, 2014 at 04:21:31PM -0500, Jason Merrill wrote:
> On 11/27/2014 01:28 AM, tsaund...@mozilla.com wrote:
> >+ if (warn_override && DECL_VIRTUAL_P (decl) && !DECL_OVERRIDE_P (decl)
>
> Why check DECL_VIRTUAL_P here?
I think it was to avoid warning when decl is hiding a non virtua
Hi,
On 12/18/2014 03:20 PM, Jason Merrill wrote:
On 12/18/2014 06:17 AM, Paolo Carlini wrote:
Sure. The below uses the c_inhibit_evaluation_warnings mechanism and
passes testing. I wondered if in such cases we could alternately use the
warning_sentinel mechanism (moved to cp-tree.h of course) ?
Hi Jakub!
On Thu, 13 Nov 2014 19:09:49 +0100, Jakub Jelinek wrote:
> > --- gcc/builtins.c
> > +++ gcc/builtins.c
> > +static rtx
> > +expand_builtin_acc_on_device (tree exp, rtx target ATTRIBUTE_UNUSED)
> > +{
> > + if (!validate_arglist (exp, INTEGER_TYPE, VOID_TYPE))
> > +return NULL_RTX;
Patch has been tested with DejaGnu gcc test suite on mips32r2 cross compiler
and bootstrapped and tested on
x86_64 native compiler.
Radovan
From: Jeff Law [l...@redhat.com]
Sent: Monday, November 17, 2014 1:18 PM
To: Radovan Obradovic; gcc-patches@gcc.gn
Ping.
Thanks,
Kyrill
On 11/12/14 15:06, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00340.html
Thanks,
Kyrill
On 04/12/14 09:19, Kyrill Tkachov wrote:
On 02/12/14 22:58, Ramana Radhakrishnan wrote:
On Tue, Nov 11, 2014 at 11:55 AM, Kyrill Tkachov wrote:
Hi al
Hi!
On Thu, 30 Oct 2014 14:40:01 +0300, Ilya Verbin wrote:
> This patch allows to run non-fallback 'make check-target-libgomp'. It passes
> to
> the host compiler additional -B options with the paths to the offload
> compilers,
> since non-installed host compiler doesn't know where to find mko
Hi,
this patch adds handling of aliases within templates and tries to
resolve specialization for them.
ChangeLog
2014-12-18 Kai Tietz
PR c++/61198
* pt.c (retrieve_specialization): Handle using.
Tested on x86_64-w64-mingw32. Ok for apply?
Regards,
Kai
ChangeLog testsuite
2014-12
Hi Jakub!
On Thu, 18 Dec 2014 15:20:42 +0100, Jakub Jelinek wrote:
> So, with your latest change both compilers build:
> mkdir objmic; cd objmic
> ../configure --build=x86_64-intelmicemul-linux-gnu
> --host=x86_64-intelmicemul-linux-gnu --target=x86_64-intelmicemul-linux-gnu
> --enable-as-accel
Hello Ramana,
I don't know if you have started to look at it, but the attribute
support fails after upgrading.
This patch aims to catch up on the changes around the fipa_ra
-masm-syntax-unified options since the initial posting. They were not
tested/supported with the attribute, and of cours
On Thu, Dec 18, 2014 at 02:48:32PM +0100, Thomas Schwinge wrote:
> > Like for CILK, I'd strongly prefer if for the clauses that are
> > specific to OpenACC only you'd use PRAGMA_OACC_CLAUSE_* instead,
> > and put them after the PRAGMA_CILK_* enum values.
> > If you want to have PRAGMA_OACC_CLAUSE_
On Thu, Dec 18, 2014 at 12:07:01PM +0100, Thomas Schwinge wrote:
> Many thanks for the review comments! The very most have been addresed,
> here are just a few comments. If you feel strongly/differently about
> any, I'll address those, too.
So, with your latest change both compilers build:
mkdir
On 12/18/2014 06:17 AM, Paolo Carlini wrote:
Sure. The below uses the c_inhibit_evaluation_warnings mechanism and
passes testing. I wondered if in such cases we could alternately use the
warning_sentinel mechanism (moved to cp-tree.h of course) ?
That would make sense to me.
Jason
On Thu, Dec 18, 2014 at 3:09 PM, H.J. Lu wrote:
> The Linux kernel never passes floating point arguments around, vararg
> functions or not. Hence no vector registers are ever used when calling a
> vararg function. But gcc still dutifully emits an "xor %eax,%eax" before
> each and
On Thu, Dec 18, 2014 at 6:03 AM, Uros Bizjak wrote:
> On Thu, Dec 18, 2014 at 2:49 PM, Uros Bizjak wrote:
>
The Linux kernel never passes floating point arguments around, vararg
functions or not. Hence no vector registers are ever used when calling a
vararg function. But gcc still
On Thu, Dec 18, 2014 at 2:49 PM, Uros Bizjak wrote:
>>> The Linux kernel never passes floating point arguments around, vararg
>>> functions or not. Hence no vector registers are ever used when calling a
>>> vararg function. But gcc still dutifully emits an "xor %eax,%eax" before
>>> each and eve
On Thu, Dec 18, 2014 at 5:51 AM, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 02:24:06PM +0100, Uros Bizjak wrote:
>> > It removed 14309 redundant "xor %eax,%eax" instructions and saved about
>> > 27KB. I am currently running the new kernel without any problem. OK
>> > for trunk?
>>
>> How abo
On Thu, Dec 18, 2014 at 02:24:06PM +0100, Uros Bizjak wrote:
> > It removed 14309 redundant "xor %eax,%eax" instructions and saved about
> > 27KB. I am currently running the new kernel without any problem. OK
> > for trunk?
>
> How about skipping RAX setup unconditionally for !TARGET_SSE? Please
On Thu, Dec 18, 2014 at 2:24 PM, Uros Bizjak wrote:
> On Thu, Dec 18, 2014 at 2:11 PM, H.J. Lu wrote:
>> The Linux kernel never passes floating point arguments around, vararg
>> functions or not. Hence no vector registers are ever used when calling a
>> vararg function. But gcc still dutifully e
Hi!
On Thu, 13 Nov 2014 14:02:37 +0100, Jakub Jelinek wrote:
> > void
> > init_pragma (void)
> > {
> > + if (flag_openacc)
> > +{
> > + const int n_oacc_pragmas
> > + = sizeof (oacc_pragmas) / sizeof (*oacc_pragmas);
> > + int i;
> > +
> > + for (i = 0; i < n_oacc_pragmas
>>>>>>>>>>>>>> comments
>>>>>>>>>>>>>> for predicate_arbitrary_scalar_phi).
>>>>>>>>>>>>>
>>>>>>>>>>>>> How so? We can always use !(condition) for the "last" value, thus
>>>>>>>>>>>>> treat it as an 'else' case. That even works for
>>>>>>>>>>>>>
>>>>>>>>>>>>> # res_1 = PHI
>>>>>>>>>>>>>
>>>>>>>>>>>>> where the condition for edges 5 and 7 can be computed as
>>>>>>>>>>>>> ! (condition for 3 || condition for 4).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Of course it is worthwhile to also sort single-occurances first
>>>>>>>>>>>>> so your case gets just the condiiton for edge 5 and its inversion
>>>>>>>>>>>>> used for edges 3 and 4 combined.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. Why we need to introduce find_insertion_point?
>>>>>>>>>>>>>> Let's consider another test-case extracted from 175.vpr ( t5.c
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> attached) and we can see that bb_7 and bb_9 containig phi nodes
>>>>>>>>>>>>>> has
>>>>>>>>>>>>>> only critical incoming edges and both contain code computing edge
>>>>>>>>>>>>>> predicates, e.g.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>> # xmax_edge_30 = PHI
>>>>>>>>>>>>>> _46 = xmax_17 == xmax_37;
>>>>>>>>>>>>>> _47 = xmax_17 == xmax_27;
>>>>>>>>>>>>>> _48 = _46 & _47;
>>>>>>>>>>>>>> _53 = xmax_17 == xmax_37;
>>>>>>>>>>>>>> _54 = ~_53;
>>>>>>>>>>>>>> _55 = xmax_17 == xmax_27;
>>>>>>>>>>>>>> _56 = _54 & _55;
>>>>>>>>>>>>>> _57 = _48 | _56;
>>>>>>>>>>>>>> xmax_edge_19 = xmax_edge_39 + 1;
>>>>>>>>>>>>>> goto ;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is evident that we can not put phi predication at the block
>>>>>>>>>>>>>> beginning but need to put it after predicate computations.
>>>>>>>>>>>>>> Note also that if there are no critical edges for phi arguments
>>>>>>>>>>>>>> insertion point will be "after labels" Note also that phi result
>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> have use in this block too, so we can't put predication code to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> block end.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So the issue is that predicate insertion for edge predicates does
>>>>>>>>>>>>> not happen on the edge but somewhere else (generally impossible
>>>>>>>>>>>>> for critical edges unless you split them).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think I've told you before that I prefer simple solutions to
>>>>>>>>>>>>> such issues,
>>>>>>>>>>>>> like splitting the edge! Certainly not involving a function
>>>>>>>>>>>>> walking
>>>>>>>>>>>>> GENERIC expressions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Richard.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Let me know if you still have any questions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>> Yuri.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2014-11-28 15:43 GMT+03:00 Richard Biener
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>> On Wed, Nov 12, 2014 at 2:35 PM, Yuri Rumyantsev
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here is the second patch related to extended predication.
>>>>>>>>>>>>>>>> Few comments which explain a main goal of design.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. I don't want to insert any critical edge splitting since it
>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>> lead to less efficient binaries.
>>>>>>>>>>>>>>>> 2. One special case of extended PHI node predication was
>>>>>>>>>>>>>>>> introduced
>>>>>>>>>>>>>>>> when #arguments is more than 2 but only two arguments are
>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>> and one argument has the only occurrence. For such PHI
>>>>>>>>>>>>>>>> conditional
>>>>>>>>>>>>>>>> scalar reduction is applied.
>>>>>>>>>>>>>>>> This is correspondent to the following statement:
>>>>>>>>>>>>>>>> if (q1 && q2 && q3) var++
>>>>>>>>>>>>>>>> New function phi_has_two_different_args was introduced to
>>>>>>>>>>>>>>>> detect such phi.
>>>>>>>>>>>>>>>> 3. Original algorithm for PHI predication used assumption that
>>>>>>>>>>>>>>>> at
>>>>>>>>>>>>>>>> least one incoming edge for blocks containing PHI is not
>>>>>>>>>>>>>>>> critical - it
>>>>>>>>>>>>>>>> guarantees that all computations related to predicate of
>>>>>>>>>>>>>>>> normal edge
>>>>>>>>>>>>>>>> are already inserted above this block and
>>>>>>>>>>>>>>>> code related to PHI predication can be inserted at the
>>>>>>>>>>>>>>>> beginning of
>>>>>>>>>>>>>>>> block. But this is not true for critical edges for which
>>>>>>>>>>>>>>>> predicate
>>>>>>>>>>>>>>>> computations are in the block where code for phi predication
>>>>>>>>>>>>>>>> must be
>>>>>>>>>>>>>>>> inserted. So new function find_insertion_point is introduced
>>>>>>>>>>>>>>>> which is
>>>>>>>>>>>>>>>> simply found out the last statement in block defining
>>>>>>>>>>>>>>>> predicates
>>>>>>>>>>>>>>>> correspondent to all incoming edges and insert phi predication
>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>> after it (with some minor exceptions).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Unfortunately the patch doesn't apply for me - I get
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> patch: malformed patch at line 505: @@ -1720,6 +2075,8 @@
>>>>>>>>>>>>>>> predicate_all_scalar_phis (struct loop *loop)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> a few remarks nevertheless. I don't see how we need both
>>>>>>>>>>>>>>> predicate_extended_scalar_phi and
>>>>>>>>>>>>>>> predicate_arbitrary_scalar_phi.
>>>>>>>>>>>>>>> Couldn't we simply sort an array of (edge, value) pairs after
>>>>>>>>>>>>>>> value
>>>>>>>>>>>>>>> and handle equal values specially in
>>>>>>>>>>>>>>> predicate_extended_scalar_phi?
>>>>>>>>>>>>>>> That would even make PHI more optimal.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't understand the need for find_insertion_point. All SSA
>>>>>>>>>>>>>>> names
>>>>>>>>>>>>>>> required for the predicates are defined upward - and the
>>>>>>>>>>>>>>> complex CFG
>>>>>>>>>>>>>>> is squashed to a single basic-block, thus the defs will
>>>>>>>>>>>>>>> dominate the
>>>>>>>>>>>>>>> inserted code if you insert after labels just like for the
>>>>>>>>>>>>>>> other case.
>>>>>>>>>>>>>>> Or what am I missing? ("flattening" of the basic-blocks of
>>>>>>>>>>>>>>> course needs
>>>>>>>>>>>>>>> to happen in dominator order - but I guess that happens
>>>>>>>>>>>>>>> already?)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd like the extended PHI handling to be enablable by a flag
>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>> for !force-vectorization - I've seen cases with 3 PHI args
>>>>>>>>>>>>>>> multiple
>>>>>>>>>>>>>>> times that would have been nice to vectorize. I suggest to
>>>>>>>>>>>>>>> add -ftree-loop-if-convert-aggressive for this. We can do this
>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>> followup, but please rename the local flag_force_vectorize flag
>>>>>>>>>>>>>>> to something less looking like a flag, like simply 'aggressive'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Otherwise patch 2 looks ok to me.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Richard.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ChangeLog:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2014-10-24 Yuri Rumyantsev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * tree-if-conv.c (ifcvt_can_use_mask_load_store): Use
>>>>>>>>>>>>>>>> FLAG_FORCE_VECTORIZE instead of loop flag.
>>>>>>>>>>>>>>>> (if_convertible_bb_p): Allow bb has more than 2 predecessors if
>>>>>>>>>>>>>>>> FLAG_FORCE_VECTORIZE is true.
>>>>>>>>>>>>>>>> (if_convertible_bb_p): Delete check that bb has at least one
>>>>>>>>>>>>>>>> non-critical incoming edge.
>>>>>>>>>>>>>>>> (phi_has_two_different_args): New function.
>>>>>>>>>>>>>>>> (is_cond_scalar_reduction): Add argument EXTENDED to choose
>>>>>>>>>>>>>>>> access
>>>>>>>>>>>>>>>> to phi arguments. Invoke phi_has_two_different_args to get phi
>>>>>>>>>>>>>>>> arguments if EXTENDED is true. Change check that block
>>>>>>>>>>>>>>>> containing reduction statement candidate is predecessor
>>>>>>>>>>>>>>>> of phi-block since phi may have more than two arguments.
>>>>>>>>>>>>>>>> (convert_scalar_cond_reduction): Add argument BEFORE to insert
>>>>>>>>>>>>>>>> statement before/after gsi point.
>>>>>>>>>>>>>>>> (predicate_scalar_phi): Add argument false (which means
>>>>>>>>>>>>>>>> non-extended
>>>>>>>>>>>>>>>> predication) to call of is_cond_scalar_reduction. Add argument
>>>>>>>>>>>>>>>> true (which correspondent to argument BEFORE) to call of
>>>>>>>>>>>>>>>> convert_scalar_cond_reduction.
>>>>>>>>>>>>>>>> (get_predicate_for_edge): New function.
>>>>>>>>>>>>>>>> (predicate_arbitrary_scalar_phi): New function.
>>>>>>>>>>>>>>>> (predicate_extended_scalar_phi): New function.
>>>>>>>>>>>>>>>> (find_insertion_point): New function.
>>>>>>>>>>>>>>>> (predicate_all_scalar_phis): Add two boolean variables
>>>>>>>>>>>>>>>> EXTENDED and
>>>>>>>>>>>>>>>> BEFORE. Initialize EXTENDED to true if BB containing phi has
>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>> than 2 predecessors or both incoming edges are critical. Invoke
>>>>>>>>>>>>>>>> find_phi_replacement_condition and predicate_scalar_phi or
>>>>>>>>>>>>>>>> find_insertion_point and predicate_extended_scalar_phi
>>>>>>>>>>>>>>>> depending on
>>>>>>>>>>>>>>>> EXTENDED value.
>>>>>>>>>>>>>>>> (insert_gimplified_predicates): Add check that non-predicated
>>>>>>>>>>>>>>>> block
>>>>>>>>>>>>>>>> may have statements to insert. Insert predicate of BB just
>>>>>>>>>>>>>>>> after label
>>>>>>>>>>>>>>>> if FLAG_FORCE_VECTORIZE is true.
>>>>>>>>>>>>>>>> (tree_if_conversion): Add initialization of
>>>>>>>>>>>>>>>> FLAG_FORCE_VECTORIZE which
>>>>>>>>>>>>>>>> is copy of inner or outer loop field force_vectorize.
patch.20141218
Description: Binary data
On 12/17/2014 04:23 PM, Richard Biener wrote:
On Wed, Dec 17, 2014 at 12:17 PM, Martin Liška wrote:
On 12/11/2014 01:37 PM, Richard Biener wrote:
On Wed, Dec 10, 2014 at 1:18 PM, Martin Liška wrote:
Hello.
As suggested by Richard, I split compare_operand functions to various
functions
rel
Hello.
Following patch is fix for PR64330, is pre-approved by Honza and I'm going to
install it.
No regression was seen on x86_64-linux-pc.
Thanks,
Martin
>From 6f9ed17a2897be6a26e2c64f8e581771c216e41b Mon Sep 17 00:00:00 2001
From: mliska
Date: Wed, 17 Dec 2014 19:11:48 +0100
Subject: [PATCH]
On Thu, 18 Dec 2014, Kyrill Tkachov wrote:
> I see that there are some intrinsics implemented in terms of __builtin_fabsf,
> presumable they can be at 'risk' too of having a library call emitted?
The semantics of fabsf/fabs/fabsl are to clear the sign bit, never raise
any exceptions (even for si
On Thu, Dec 18, 2014 at 2:11 PM, H.J. Lu wrote:
> The Linux kernel never passes floating point arguments around, vararg
> functions or not. Hence no vector registers are ever used when calling a
> vararg function. But gcc still dutifully emits an "xor %eax,%eax" before
> each and every call of a
Hi Jakub!
On Thu, 18 Dec 2014 13:36:16 +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 01:31:45PM +0100, Jakub Jelinek wrote:
> > > --- gcc/config.gcc
> > > +++ gcc/config.gcc
> > > @@ -2906,6 +2906,7 @@ esac
> > > case ${target} in
> > > *-intelmic-* | *-intelmicemul-*)
> > > tmake_fil
Hi Jakub!
On Thu, 18 Dec 2014 12:33:11 +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 11:46:00AM +0100, Thomas Schwinge wrote:
> > > just
> > > rtx v1 = GEN_INT (...);
> > > rtx v2 = GEN_INT (...);
> > > machine_mode mode = TYPE_MODE (TREE_TYPE (arg));
> > > rtx ret = gen_reg_rtx (
The Linux kernel never passes floating point arguments around, vararg
functions or not. Hence no vector registers are ever used when calling a
vararg function. But gcc still dutifully emits an "xor %eax,%eax" before
each and every call of a vararg function. Since no callee use that for
anything,
On Thu, Dec 18, 2014 at 01:31:45PM +0100, Jakub Jelinek wrote:
> > --- gcc/config.gcc
> > +++ gcc/config.gcc
> > @@ -2906,6 +2906,7 @@ esac
> > case ${target} in
> > *-intelmic-* | *-intelmicemul-*)
> > tmake_file="${tmake_file} i386/t-intelmic"
> > + tm_file="${tm_file} i386/intelmic-offlo
On Thu, Dec 18, 2014 at 01:24:20PM +0100, Thomas Schwinge wrote:
> Hi Jakub!
>
> On Thu, 18 Dec 2014 13:15:38 +0100, Jakub Jelinek wrote:
> > On Thu, Dec 18, 2014 at 01:02:22PM +0100, Jakub Jelinek wrote:
> > > On Thu, Dec 18, 2014 at 12:38:53PM +0100, Jakub Jelinek wrote:
> > > > So, is what is
Hi Jakub!
On Thu, 18 Dec 2014 13:15:38 +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 01:02:22PM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 18, 2014 at 12:38:53PM +0100, Jakub Jelinek wrote:
> > > So, is what is on the gomp-4_0-branch now all that you'd like to merge to
> > > trunk now?
On Thu, Dec 18, 2014 at 01:02:22PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 18, 2014 at 12:38:53PM +0100, Jakub Jelinek wrote:
> > So, is what is on the gomp-4_0-branch now all that you'd like to merge to
> > trunk now? Has it been tested on nvptx? I guess we should test it with
> > XeonPhi offl
On Tue, Dec 16, 2014 at 06:58:47PM +, Joseph Myers wrote:
> On Fri, 12 Dec 2014, Jakub Jelinek wrote:
>
> > Hi!
> >
> > -fsanitize=float-cast-overflow sanitization is done in convert.c and calls
> > there save_expr. Unfortunately, save_expr is a no-go for the C FE, we need
> > c_save_expr, b
On Thu, Dec 18, 2014 at 12:38:53PM +0100, Jakub Jelinek wrote:
> So, is what is on the gomp-4_0-branch now all that you'd like to merge to
> trunk now? Has it been tested on nvptx? I guess we should test it with
> XeonPhi offloading too to make sure it doesn't break.
> And then you or together wi
On 17/12/14 00:04, Joseph Myers wrote:
On Mon, 15 Dec 2014, James Greenhalgh wrote:
@@ -22792,6 +22792,12 @@ vsqrtq_f32 (float32x4_t a)
return __builtin_aarch64_sqrtv4sf (a);
}
+__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
+vsqrt_f64 (float64x1_t a)
+
On Thu, Dec 18, 2014 at 12:07:01PM +0100, Thomas Schwinge wrote:
> > > - case GF_OMP_FOR_KIND_SIMD:
> > > - kind = " simd";
> > > - break;
> > > - case GF_OMP_FOR_KIND_CILKSIMD:
> > > - kind = " cilksimd";
> > > - break;
> > > case GF_OMP_FOR_KIND_DISTRIBUTE:
> > > kind = " distribute
On Thu, Dec 18, 2014 at 11:46:00AM +0100, Thomas Schwinge wrote:
> > just
> > rtx v1 = GEN_INT (...);
> > rtx v2 = GEN_INT (...);
> > machine_mode mode = TYPE_MODE (TREE_TYPE (arg));
> > rtx ret = gen_reg_rtx (TYPE_MODE (integer_type_node));
> > emit_move_insn (ret, const0_rtx);
> > rtx
1 - 100 of 110 matches
Mail list logo
