> On Jun 8, 2017, at 6:13 PM, Richard Earnshaw (lists)
> wrote:
>
> On 08/06/17 14:47, James Greenhalgh wrote:
>> On Mon, Jan 30, 2017 at 08:35:00AM -0800, Andrew Pinski wrote:
>>> On Mon, Jan 30, 2017 at 3:48 AM, Maxim Kuvyrkov
>>> wrote:
This patch port prefetch configuration from aarch3
On Wed, Jun 7, 2017 at 4:46 AM, Richard Biener wrote:
>
> When the order of visiting dominator children in domwalk changed
> GRAPHITE falls foul of relying on a particular order BBs are visited
> when computing the original schedule from the vector of pbbs.
>
> The following restores an order that
On 8 June 2017 17:27:24 CEST, Jan Hubicka wrote:
>Hi,
>this patch adds cold attributes to (some of) our internal checking.
Exactly.
Same for anything touching stderr.
/me hides
> On Tue, Jun 6, 2017 at 1:00 AM, Jan Hubicka wrote:
> >> On Thu, Jun 1, 2017 at 4:35 AM, Jan Hubicka wrote:
> >> > Index: profile.c
> >> > ===
> >> > --- profile.c (revision 248684)
> >> > +++ profile.c (working copy)
> >> > @@
Hi All,
I have reverted the patch in commit r 249050 until I can fix the late expansion
and IBM long double issues.
Thanks for the feedback,
Tamar
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: 09 June 2017 06:19
> To: David Edelsohn
> Cc: Tamar Christ
> For a built-in this is generally valid. For plain isnan it depends on what
> the
> standard says.
>
> You have to support taking the address of isnan anyway and thus expanding
> to a library call in that case. Why doesn't that not work?
Only because I had put a failsafe in builtins.c with a
Hi,
this patch adds effective target signal.
Atm, -DSIGNAL_SUPPRESS is defined at top-level in gcc_target_compile
resulting in the macro being passed down to ~30k compilations. The macro
is used in just 17 testcases.
The patch defines an effective target signal, which is used in:
- individu
Hello,
This is a follow-up improvement over the change
introduced from
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00414.html
<< self-specs setup with configure --with-specs are allowed to contain %:getenv
environment variable references. We are using this capability in a few cases
for c
On Thu, Jun 08, 2017 at 05:05:15PM +0100, Nick Clifton wrote:
> >> Regardless, the point of this patch is to record which options were
> >> enabled, via
> >> whatever route, in the binaries. This can be useful to users, or
> >> distributors,
> >> who want to check that, for example, a specific s
> > + /* Optimize routines for MEM to REG copies. */ if (n < 8 &&
> > + !REG_P (XEXP (operands[0], 0)))
>
> This seems to be checking that the address of the original destination
> memory isn't a plain base register. Why's it important to reject that case
> but
> allow e.g. base+offset?
>
I
Hi,
On 9 June 2017 at 08:43, Bernhard Reutner-Fischer wrote:
> On 8 June 2017 14:52:49 CEST, Jan Hubicka wrote:
>>Hi,
>>this patch adds static code to detect basic block with 0 execution
>>count.
>>Those are basic block either reached only by EH or those which leads to
>>call of
>>function deco
On 06/08/2017 03:47 PM, Jakub Jelinek wrote:
Hi!
I'd still prefer to handle it with the flags infrastructure instead, but if
Richard wants to do it this way, then at least:
On Thu, Jun 08, 2017 at 03:30:49PM +0200, Martin Liška wrote:
+/* Return true when flag_sanitize & FLAG is non-zero. If
On Thu, 8 Jun 2017, Jakub Jelinek wrote:
> Hi!
>
> force_gimple_operand_gsi called by update_range_test can using match.pd
> simplifications sometimes return INTEGER_CST (especially when cunroll
> unrolled code isn't really optimized by forwprop/ccp and similar passes
> before reassoc2), but that
On Fri, Jun 09, 2017 at 11:29:48AM +0200, Richard Biener wrote:
> > force_gimple_operand_gsi called by update_range_test can using match.pd
> > simplifications sometimes return INTEGER_CST (especially when cunroll
> > unrolled code isn't really optimized by forwprop/ccp and similar passes
> > befor
On Fri, Jun 09, 2017 at 11:29:06AM +0200, Martin Liška wrote:
> Having that inlined would be great, however we'll need to put it to tree.h
> and thus we have to include "options.h" before tree.h in multiple source
> files.
Doesn't that mean that tree.h is not the right header to put this into?
It
On Wed, Jun 07, 2017 at 12:38:22PM +0100, Tamar Christina wrote:
> Hi All,
>
> This patch optimizes integer moves for cases where where the move could be
> done
> move efficiently using a smaller mode.
>
> For example:
>
> long long f1(void)
> {
> return 0x;
> }
>
> long f2(void)
>
> Since this commit (r249013), I've noticed a regression on arm targets:
> FAIL: gcc.target/arm/cold-lc.c scan-assembler-not bl[^\n]*dump_stack
I think that is because we optimize the testcase:
/* { dg-do compile } */
/* { dg-options "-O2 -mlong-calls" } */
/* { dg-final { scan-assembler-not "bl\[
On Fri, Jun 09, 2017 at 10:30:02AM +0300, Maxim Kuvyrkov wrote:
> > On Jun 8, 2017, at 6:13 PM, Richard Earnshaw (lists)
> > wrote:
> >
> > On 08/06/17 14:47, James Greenhalgh wrote:
> >> On Mon, Jan 30, 2017 at 08:35:00AM -0800, Andrew Pinski wrote:
> >>> On Mon, Jan 30, 2017 at 3:48 AM, Maxim
On Fri, Jun 9, 2017 at 7:14 AM, Ian Lance Taylor wrote:
> This recent patch
> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00518.html turned on
> block partitioning even when profiling is not enabled. This can break
> code compiled with -fsplit-stack, if the cold partition calls a
> function tha
Hi Tamar,
On 07/06/17 16:09, Tamar Christina wrote:
Hi Kyrill,
I have updated the patch and regtested on arm-none-linux-gnueabihf.
OK for trunk?
Ok.
Thanks,
Kyrill
Thanks,
Tamar
From: Tamar Christina
Sent: Wednesday, June 7, 2017 11:15:49 AM
To: Kyr
On Fri, Jun 9, 2017 at 11:29 AM, Martin Liška wrote:
> On 06/08/2017 03:47 PM, Jakub Jelinek wrote:
>>
>> Hi!
>>
>> I'd still prefer to handle it with the flags infrastructure instead, but
>> if
>> Richard wants to do it this way, then at least:
>>
>> On Thu, Jun 08, 2017 at 03:30:49PM +0200, Mart
> This recent patch
> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00518.html turned on
> block partitioning even when profiling is not enabled. This can break
I am heading towards enabling block partitioning by default (because we now
have infrastructure to identify likely cold BBs), but I must
On 06/09/2017 12:12 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 11:29 AM, Martin Liška wrote:
On 06/08/2017 03:47 PM, Jakub Jelinek wrote:
Hi!
I'd still prefer to handle it with the flags infrastructure instead, but
if
Richard wants to do it this way, then at least:
On Thu, Jun 08, 201
Hi,
This patch adds support for devices that can access flash memory
by LD* instructions, hence there is no need to put .rodata in RAM.
The default linker script for the new multilib versions already
supports this feature, it's similar to avrtiny, cf.
https://sourceware.org/PR21472
This patch
Ping #1
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00096.html
On 02.06.2017 09:53, Georg-Johann Lay wrote:
Hi,
this small addition improves costs of PARALLELs in
rtlanal.c:seq_cost(). Up to now, these costs are
assumed to be 1 which gives gross inexact costs for,
e.g. divmod which is repre
On Fri, Jun 9, 2017 at 12:17 PM, Martin Liška wrote:
> On 06/09/2017 12:12 PM, Richard Biener wrote:
>>
>> On Fri, Jun 9, 2017 at 11:29 AM, Martin Liška wrote:
>>>
>>> On 06/08/2017 03:47 PM, Jakub Jelinek wrote:
Hi!
I'd still prefer to handle it with the flags infrastruc
Occured to me when looking into PR81028.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2017-06-09 Richard Biener
* tree-ssa-loop-im.c (execute_sm): Do not force multi-threaded
model if the ref is always written to.
Index: gcc/tree-ssa-loop-im.c
===
On 06/09/2017 12:39 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:17 PM, Martin Liška wrote:
On 06/09/2017 12:12 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 11:29 AM, Martin Liška wrote:
On 06/08/2017 03:47 PM, Jakub Jelinek wrote:
Hi!
I'd still prefer to handle it with the
On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
> On 06/09/2017 12:39 PM, Richard Biener wrote:
>>
>> On Fri, Jun 9, 2017 at 12:17 PM, Martin Liška wrote:
>>>
>>> On 06/09/2017 12:12 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 11:29 AM, Martin Liška wrote:
>
>
>>
More deduction guides for C++17.
* include/bits/forward_list.h (forward_list): Add deduction guide.
* include/bits/stl_deque.h (deque): Likewise.
* include/bits/stl_list.h (list): Likewise.
* include/bits/stl_vector.h (vector): Likewise.
* testsuite/23_cont
Hi Tamar,
> I have reverted the patch in commit r 249050 until I can fix the late
> expansion
> and IBM long double issues.
thanks. Just for the record, Solaris/SPARC (also big-endian) was
affected as well:
https://gcc.gnu.org/ml/gcc-testresults/2017-06/msg00908.html
Rainer
-
On 06/09/2017 01:05 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
On 06/09/2017 12:39 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:17 PM, Martin Liška wrote:
On 06/09/2017 12:12 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 11:29 AM, Martin Liš
On 06/09/2017 11:42 AM, Jakub Jelinek wrote:
On Fri, Jun 09, 2017 at 11:29:06AM +0200, Martin Liška wrote:
Having that inlined would be great, however we'll need to put it to tree.h
and thus we have to include "options.h" before tree.h in multiple source files.
Doesn't that mean that tree.h is
Hello.
I discussed with Honza possibility to speed-up instrumentation that we do for
indirect call target tracking. By direct emission of:
if (__gcov_indirect_call_callee != NULL)
__gcov_indirect_call_profiler_v2 (profile_id, ¤t_function_decl);
we can save reduce # of execution of _
Hi Ilya,
I tried changing builtin call so it gets address of a decl instead of
a decl, but it looked very unnatural and I hit some other problems
implementing that. Keeping in mind the exposure of this problem, I
think it is not worth it. I propose to reconsider the first and the
simplest patch in
> Hello.
>
> I discussed with Honza possibility to speed-up instrumentation that we do for
> indirect call target tracking. By direct emission of:
>
> if (__gcov_indirect_call_callee != NULL)
>__gcov_indirect_call_profiler_v2 (profile_id, ¤t_function_decl);
>
> we can save reduce #
On Fri, Jun 9, 2017 at 2:08 PM, Martin Liška wrote:
> On 06/09/2017 01:05 PM, Richard Biener wrote:
>>
>> On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
>>>
>>> On 06/09/2017 12:39 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:17 PM, Martin Liška wrote:
>
>
>>>
On 07/06/17 16:42, Thomas Preudhomme wrote:
> Hi,
>
> The general arm_arch_*_ok procedures check architecture availability by
> substituting macros inside a defined preprocessor operator. This limits
> them to only check definition of only one macro and force ARMv7VE to be
> special cased.
>
> Th
On Thu, Jun 8, 2017 at 6:29 PM, Martin Sebor wrote:
> On 06/08/2017 01:51 AM, Richard Biener wrote:
>>
>> On Thu, Jun 8, 2017 at 4:33 AM, Martin Sebor wrote:
>>>
>>> On 06/07/2017 02:12 PM, Martin Sebor wrote:
On 06/07/2017 02:01 PM, Marc Glisse wrote:
>
>
> On Wed, 7 J
On Thu, 8 Jun 2017, Yuri Gribov wrote:
> On Wed, May 31, 2017 at 12:19 PM, Richard Biener wrote:
> > On Mon, 29 May 2017, Yuri Gribov wrote:
> >
> >> This no longer fixes the PR but still works in some cases as
> >> demonstrated by the test. So I decided to keep it.
> >
> > As Richard noticed you
On Thu, 8 Jun 2017, Yuri Gribov wrote:
> On Tue, May 30, 2017 at 7:25 AM, Richard Sandiford
> wrote:
> > Yuri Gribov writes:
> >> Added special case to build_range_check. Fixed couple of existing
> >> tests where it changed codegen.
> >>
> >> -I
> >>
> >> From b7819f341e2ffa0437be497024f61d0a4e1
On 06/09/2017 02:27 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 2:08 PM, Martin Liška wrote:
On 06/09/2017 01:05 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
On 06/09/2017 12:39 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:17 PM, Martin Lišk
The assembler doesn't understand -mfpu=auto. The easiest way to handle this
is to surpress this value from being passed through, while still passing
through legacy values.
* config/arm/elf.h (ASM_SPEC): Only pass -mfpu through to the
assembler when it is not -mfpu=auto.
---
gcc/
In order to support more complex specifications for cpus and architectures
we need to move away from using enumerations to represent the set of
permitted options. This basic change just moves the option parsing
infrastructure over to that, but changes nothing more beyond generating
a hint when th
The assembler does not understand all the '+' options accepted by the
compiler. The best solution to this is to simply strip the extensions
and just pass the raw architecture or cpu name through to the
assembler. We will use .arch and .arch_extension directives anyway to
turn on or off individua
During the ARM BoF at the Cauldron last year I mentioned that I wanted
to rework the way GCC on ARM handles the command line options. The
problem was that most users, and even many experts, can't remember
which FPU/SIMD unit comes with which CPU and that consequently many
users were inadvertenly
This patch adds the default CPUs for each cpu and provides options for
changing the FPU variant when appropriate.
It turns out to be easier to describe removal options using general
mask operations that disable a concept rather than specific bits.
Sometimes the helper definitions for enabling a f
This patch adds the currently supported architecture options to the
individual architectures. For floating point and SIMD we only permit
variants that the relevant versions of the architecture permit. We also
add short-hand versions (+fp, +simd, etc) that allows the user to
describe using floati
The ARM option parsing code uses sbitmap data structures to manage
features and upcoming patches will shortly need to use these bitmaps
within the driver. This patch moves sbitmap.o from OBJS to
OBJS-libcommon to facilitate this.
The patch has no impact on targets that don't need this functional
This patch extends support for the new extended-style architecture
strings to configure and the target default options. We validate any
options passed by the user to configure against the permitted
extensions for that CPU or architecture.
* config.gcc (arm*-*-fucshia*): Set target_cpu_cn
This file is missing a .fpu directive and was relying on the compiler
driver passing through a -mfpu= command line option. When the FPU is
auto, that will not be passed through correctly, so set something
suitable within the file itself.
libgcc:
* config/arm/cmse_nonsecure_call.S: Expli
Some tests explicitly test with -march=armv7-a and -mfloat-abi=hard.
However, with the new -mfpu=auto code, this architectural specifiction
lacks any floating-point capabilities. To rectify this, change the
architecture to armv7-a+fp.
gcc/testsuite:
* gcc.dg/pr59418.c: On ARM, change ar
Now that the standard CPU and architecture option parsing code is
available in the driver we can use the main CPU and architecture data
tables for driving the automatic enabling of Thumb code.
Doing this requires that the driver script tell the parser whether or
not the target string is a CPU nam
[This patch has only been fairly lightly tested (I've built a compiler
with all the relevant multilibs and smoke-tested a few combinations to
check that the tools still produce a sensible object file).]
This patch updates the RTEMS build to use the new option framework.
It tries as far as possibl
NB. This configuration does not build in GCC-7 and doesn't build now either.
This patch resets a couple of multlib variables which previously were
not cleared.
It almost certainly needs further work to make it use the new option
framework correctly, but since the library configurations are alre
This is the main patch to provide the infrastructure for adding
feature extensions to CPU and architecture specifications. It does not,
however, add all the extensions that we intend to support (just a small
number to permit some basic testing). Now, instead of having specific
entries in the arc
This patch adds the remainder of the main documentation changes. It
adds the changes for -mcpu, -mtune and -mfpu. I've chosen to document
the extension options under -mcpu rather than under -mtune because, while
they are permitted with -mtune, they do not affect the behaviour of the tuning
done
This adds documentation for the new extension options to -march= on ARM.
I tried a number of different ways of formatting the information, but this
seems the best, given what can be achieved in texinfo format.
* doc/invoke.texi (ARM Options, -march=): Document new syntax and
permi
Now that the default FPU is 'auto' we can finally rewrite (and
simplify) the rules for mapping compiler options to multilibs. We
no-longer need to know the specific CPU, since the driver will
construct a suitable -march flag for us; this greatly simplifies the
overall logic. This patch rewrites
It looks like the fuchsia port relied on inheriting the multilib rules from
the bare-metal port (the t-arm-elf makefile fragment), but that has now been
rewritten on the assuption that the base architecture is ARMv4t; fuchsia
has a base architecture of ARMv7-a.
To account for this, I've cloned th
Reviewing the list of options for the purposes of writing the
documentation revealed that a small number of options were missing.
Mostly these are aliases for existing options, but in a couple of
cases we lacked the ability to disable certain other options.
* config/arm/arm-cpus.in (armv7
No real change, but for consistency reset all multilib related variables.
config/arm/t-linux-eabi (MULTILIB_EXCEPTIONS): Set to empty.
(MULTILIB_RESUE): Likewise.
(MULTILIB_MATCHES): Likewise.
(MULTLIB_REQUIRED): Likewise.
---
gcc/config/arm/t-linux-eabi | 4
Symbianelf used to build multilib for armv5t with softfp, but that
architecture doesn't really support floating point instructions. This
patch reworks the multilib configuration to use armv5te as the base
when building for floating point.
I'm not sure just how useful the symbian port is these da
This patch has no functional change. The code used for parsing -mcpu,
-mtune and -march options is simply moved from arm.c arm-common.c.
The list of FPU options is also moved. Subsequent patches will make
use of this within the driver.
Some small adjustments are needed as a consequence of movin
The driver really needs to handle some canonicalization of the new
-mcpu and -march options in order to make multilib selection
tractable. This will require moving much of the logic to parse the
new options into the common code file. However, the tuning data
definitely does not want to be there
The MULTILIB_REUSE mapping rules are built up using periods to
represent the placement of '=' signs in the command line syntax. This
presents a problem if the option contains an explicit period because
that is translated unconditionally. The result is that it is not
currently possible to write a
This is the R- & M-profile equivalent of the previous A-profile
multilib rewrite. Additionally this patch adds some top-level rules
to help find suitable multilibs for general cases when certain
libraries are not built, or when building for legacy cores.
gcc:
* config/arm/t-aprofile (v7
Before this patch series it wasn't really possible to not have an FPU;
it was always there, even if the hardware didn't really support it.
Now that we have -mfpu=auto, the concept of not having an FPU becomes
real. Consequently, when the -mfloat-abi switch is set to softfp
doing the Right Thing i
Currently if the user does not specify a default CPU or architecture
the compiler provieds no default values in the spec defaults. We can
try to work from TARGET_CPU_DEFAULT but pulling that into the driver
is a bit crufty and doesn't really work well with the general
spec-processing model. A be
A follow up patch to this one will start to canonicalize options to
simplify generating multilib fragments. This patch is enabling work
for that. If we have extension options that duplicate other options
(done principally for back-wards compatibility purposes) we need to
ensure that just one of
This patch uses the driver and some spec rewrite rules to generate a
canonicalized form of the -march= option. We want to do this for
several reasons, all relating to making multi-lib selection sane.
1) It can remove redundant extension options to produce a minimal
list.
2) The general syntax o
The standard arm-eabi configuration comes with a basic set of multilibs that
are suitable mostly for simple testing of the compiler in various
configurations. We try to keep the number of libraries build small so
that build times do not become too onerous.
Using the new auto-fp selection code we
Hello Richard,
thanks for updating the RTEMS multlib configuration. It looks fine to me.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP :
On Fri, Jun 09, 2017 at 02:35:45PM +0200, Richard Biener wrote:
> +static bool
> +gimple_fold_builtin_bcmp (gimple_stmt_iterator *gsi)
> +{
>
> + /* Transform bcmp (a, b, len) into memcmp (a, b, len). */
> +
> + gimple *stmt = gsi_stmt (*gsi);
> + tree a = gimple_call_arg (stmt, 0);
> + tree
Finally, we can make 'auto' the default choice for the FPU option. It's
still possible to override this during configure, but we will eventually
deprecate that, moving to the new cpu/architecture selection mechanism.
* config/arm/arm.h (FPUTYPE_AUTO): Define.
* config/arm/arm.c (
As required for C++17, this relaxes the requirements to allow
move-only deleters.
We can't pass them everywhere by rvalue reference, because the
constructor from std::unique_ptr can lead to construction from an
lvalue that won't bind to an rvalue reference. We could add another
_Sp_shared_deleter
On Thu, Jun 8, 2017 at 12:13 PM, Martin Sebor wrote:
> On 06/08/2017 11:00 AM, H.J. Lu wrote:
>>
>> On Wed, Jun 7, 2017 at 6:30 AM, H.J. Lu wrote:
>>>
>>> On Tue, Jun 6, 2017 at 5:11 PM, Martin Sebor wrote:
On 06/06/2017 04:57 PM, H.J. Lu wrote:
>
>
> On Tue, Jun 6, 2017 at
On Fri, Jun 9, 2017 at 2:51 PM, Martin Liška wrote:
> On 06/09/2017 02:27 PM, Richard Biener wrote:
>>
>> On Fri, Jun 9, 2017 at 2:08 PM, Martin Liška wrote:
>>>
>>> On 06/09/2017 01:05 PM, Richard Biener wrote:
On Fri, Jun 9, 2017 at 12:49 PM, Martin Liška wrote:
>
>
On Fri, Jun 9, 2017 at 3:04 PM, Jakub Jelinek wrote:
> On Fri, Jun 09, 2017 at 02:35:45PM +0200, Richard Biener wrote:
>> +static bool
>> +gimple_fold_builtin_bcmp (gimple_stmt_iterator *gsi)
>> +{
>>
>> + /* Transform bcmp (a, b, len) into memcmp (a, b, len). */
>> +
>> + gimple *stmt = gsi_st
This PR was raised because of a bootstrap failure on Darwin. The cause
was a mishandled exception raised by Rtsfind.Load_Fail while
processing g-exptty.adb. g-exptty.adb had been updated on 2017-04-25
(but so had a lot of other parts of GNAT). Since a lot of other
compilations had been performed su
On 21/02/17 16:54, charles.bay...@linaro.org wrote:
> From: Charles Baylis
>
> This patch moves the calculation of costs for MEM into a
> separate function, and reforms the calculation into two
> parts. Firstly any additional cost of the addressing mode
> is calculated, and then the cost of the m
> gcc/ChangeLog:
>
> 2017-05-26 Martin Liska
>
> * gimplify.c (gimplify_label_expr): Insert GIMPLE_PREDICT
> statements on cold and hot labels.
> * predict.c (tree_estimate_probability_bb): Remove the
> prediction from this place.
>
> gcc/testsuite/ChangeLog:
>
> 2017
> gcc/ChangeLog:
>
> 2017-05-26 Martin Liska
>
> PR tree-optimization/79489
> * gimplify.c (maybe_add_early_return_predict_stmt): New
> function.
> (gimplify_return_expr): Call the function.
> * predict.c (tree_estimate_probability_bb): Remove handling
> of
On 21/02/17 16:54, charles.bay...@linaro.org wrote:
> From: Charles Baylis
>
> This patch adds support for modelling the varying costs of
> different addressing modes. The generic cost table treats
> all addressing modes as having equal cost. The cost table
> for Cortex-A57 is derived from
> htt
On Fri, Jun 9, 2017 at 3:16 AM, Jan Hubicka wrote:
>
>> code compiled with -fsplit-stack, if the cold partition calls a
>> function that is not compiled with -fsplit-stack (such as a C library
>> function). The problem is that when the linker sees a split-stack
>> function call a non-split-stack
On Wed, Apr 26, 2017 at 06:34:36AM +, Hurugalawadi, Naveen wrote:
> Hi Kyrill,
>
> Thanks for the review and your comments.
>
> >> It would be useful if you expanded a bit on the approach used to
> >> generate the improved codegen
>
> The patch creates a duplicate of most common element and
Hi,
this patch adds effective target stack_size.
Atm, -DSTACK_SIZE= is defined at top-level in gcc_target_compile
resulting in the macro being passed down to ~30k compilations. The macro
is used in just 37 testcases.
The patch defines an effective target stack_size, which is used in
indivi
On Jun 9, 2017, at 1:25 AM, Tom de Vries wrote:
>
> Atm, -DSIGNAL_SUPPRESS is defined at top-level in gcc_target_compile
> resulting in the macro being passed down to ~30k compilations. The macro is
> used in just 17 test cases.
> OK for trunk if x86_64 and nvptx testing succeeds?
Ok.
On Jun 9, 2017, at 7:24 AM, Tom de Vries wrote:
> this patch adds effective target stack_size.
> OK for trunk if x86_64 and nvptx testing succeeds?
Ok.
The only last issue in this area that I know about is that there are a few more
test cases that need up to 48 MB to run, the problem is that t
On 8 June 2017 at 15:49, Richard Biener wrote:
> On Thu, 8 Jun 2017, Richard Biener wrote:
>
>>
>> The following fixes unsafe vectorization of reductions in outer loop
>> vectorization. It combines it with a bit of cleanup in the affected
>> function.
>>
>> Bootstrap and regtest running on x86_64
On June 9, 2017 5:32:10 PM GMT+02:00, Christophe Lyon
wrote:
>On 8 June 2017 at 15:49, Richard Biener wrote:
>> On Thu, 8 Jun 2017, Richard Biener wrote:
>>
>>>
>>> The following fixes unsafe vectorization of reductions in outer loop
>>> vectorization. It combines it with a bit of cleanup in th
> > + /* Optimize routines for MEM to REG copies. */ if (n < 8 &&
> > + !REG_P (XEXP (operands[0], 0)))
>
> This seems to be checking that the address of the original destination
> memory isn't a plain base register. Why's it important to reject that case
> but
> allow e.g. base+offset?
thi
> On Jun 9, 2017, at 1:04 PM, James Greenhalgh wrote:
>>>
...
>>> I disagree with having to write all these things out, but I do agree
>>> that we should be self-consistent within the port.
>>
>> I'm re-writing the patch with approach that James suggested, and instead of
>> AARCH64_PREFETCH_NOT_
> On Jun 8, 2017, at 7:31 PM, James Greenhalgh wrote:
>
> On Fri, Feb 03, 2017 at 02:58:23PM +0300, Maxim Kuvyrkov wrote:
>>> On Jan 30, 2017, at 5:50 PM, Maxim Kuvyrkov
>>> wrote:
>>>
On Jan 30, 2017, at 3:23 PM, Kyrill Tkachov
wrote:
Hi Maxim,
On 30/01/17 12
> On Jun 8, 2017, at 7:32 PM, James Greenhalgh wrote:
>
> On Mon, Jan 30, 2017 at 03:08:04PM +0300, Maxim Kuvyrkov wrote:
>> This patch enables software prefetching at -O3 for Qualcomm's qdf24xx cores.
>>
>> Bootstrapped and regtested on x86_64-linux-gnu and aarch64-linux-gnu.
>
> This patch is
> On May 28, 2017, at 8:01 AM, Andrew Pinski wrote:
>
> On Tue, Feb 28, 2017 at 1:53 AM, Maxim Kuvyrkov
>>
...
>> Hi Kyrill,
>>
>> My hope was to push them in time for GCC 7, but it seems to late now. I'll
>> return to these patches at the beginning of Stage 1.
>
> Ping on this patch set as
Hi,
this patch marks the obvious candidates for cold attribute and enables
cold auto-detection on some common coding patterns.
I have bootstrapped/regtested x86_64-linux and plan to commit it at
weekend once performance testers pick up this weeks changes if there
are no complains.
Honza
On 2017.06.09 at 14:17 +0200, Martin Liška wrote:
> Hello.
>
> I discussed with Honza possibility to speed-up instrumentation that we do for
> indirect call target tracking. By direct emission of:
>
> if (__gcov_indirect_call_callee != NULL)
>__gcov_indirect_call_profiler_v2 (profile
2017-06-09 15:21 GMT+03:00 Alexander Ivchenko :
> Hi Ilya,
>
> I tried changing builtin call so it gets address of a decl instead of
> a decl, but it looked very unnatural and I hit some other problems
What is unnatural in passing a pointer to a function to get its bounds?
Please show your patch a
GCC Maintainers:
This patch adds support for the various vec_float, vec_float2,
vec_floate, vec_floate, builtins.
The patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE)
and on powerpc64-unknown-linux-gnu (Power 8 BE) with no regressions.
Is the patch OK for gcc mainline?
1 - 100 of 128 matches
Mail list logo
