Multi-range selftests are unused, as we don't currently have them on
trunk. This was leftover from the original ranger branch. Removing
them has the added benefit that the selftests no longer need to peek at
m_max_pairs, so value_range no longer needs to friend the selftests.
This tidies up
On 11/13/19 11:49 PM, Jan Hubicka wrote:
Hi.
Current lto-dump.o relies on some FE generated files as
pre-requirement. That hover delays LTO linking of the lto-dump
and so that I adjusted the dependency to LTO_OBJS which will
work as well.
Patch can bootstrap on x86_64-linux-gnu and survives reg
> On Wed, Nov 13, 2019 at 10:08:23PM +0100, Jan Hubicka wrote:
> > PR c++/92421
> > * ipa-prop.c (update_indirect_edges_after_inlining):
> > Mark parameter as used.
> > * ipa-inline.c (recursive_inlining): Reset node cache
> > after inlining.
> > (inline_small_functions): Re
Hi!
NVidia recently requested replacement of pgi with nvidia. The following
patch just adds nvidia and keeps pgi, so that we don't warn on either of
those, at least for now.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2019-11-14 Jakub Jelinek
* c-omp.c
Hi!
OpenMP 5.0 is not clear enough here, but on Tuesday language committee
it was agreed that the selectors like arch/isa/kind/vendor/extension
should accept both identifiers and string literals.
kind(host) and kind("host") are then the same thing, but there can be
properties that are not valid id
On Nov 14 2019, Jakub Jelinek wrote:
> --- gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c.jj 2019-11-13
> 10:54:37.081172852 +0100
> +++ gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c2019-11-14
> 01:19:36.704285484 +0100
> @@ -2,7 +2,7 @@
>
> #include
> #include
> -#inc
Hi!
We've also agreed that score arguments need to be non-negative.
Implemented thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2019-11-14 Jakub Jelinek
* c-parser.c (c_parser_omp_context_selector): Don't require score
argument to fit into s
On Thu, Nov 14, 2019 at 09:30:42AM +0100, Andreas Schwab wrote:
> On Nov 14 2019, Jakub Jelinek wrote:
>
> > --- gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c.jj 2019-11-13
> > 10:54:37.081172852 +0100
> > +++ gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.c 2019-11-14
> > 01:19:36
Hi!
With the support for string literals, there is no need to obfuscate
sse4.2 to sse4_2; not doing it makes it easier to describe, because
the option is -msse4.2, not -msse4_2.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2019-11-14 Jakub Jelinek
* conf
On 11/13/19 5:14 PM, Uros Bizjak wrote:
On Wed, Nov 13, 2019 at 4:25 PM Martin Liška wrote:
Hi.
The patch adds a missing feature for PTA_ICELAKE_CLIENT and
inherited CPUs. One can see that:
https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
Patch can bootstrap on x86_64-linux-gnu and su
On 11/14/19 1:31 AM, Jakub Jelinek wrote:
This broke on hosts where the system compiler doesn't have
ISO_Fortran_binding.h header installed (e.g. GCC 8 and earlier).
Aha, that's the reason.
Fixed thusly, tested on x86_64-linux, committed to trunk as obvious.
2019-11-14 Jakub Jelinek
Hi,
Is it OK to backport r25 to gcc8 (Ensure dotproduct is only
enabled on armv8 neon) ?
I've noticed unnecessary failure of gcc.target/arm/simd/vdot-compile.c
after I upgraded to recent binutils.
Thanks,
Christophe
[ARM] Ensure dotproduct is only enabled on armv8 neon
2019-11-14 Christoph
On Thu, Nov 14, 2019 at 9:36 AM Martin Liška wrote:
>
> On 11/13/19 5:14 PM, Uros Bizjak wrote:
> > On Wed, Nov 13, 2019 at 4:25 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch adds a missing feature for PTA_ICELAKE_CLIENT and
> >> inherited CPUs. One can see that:
> >> https://en.wikipe
On 11/13/19 4:25 PM, Sandra Loosemore wrote:
On 11/13/19 6:45 AM, Martin Liška wrote:
Hi.
The patch is about a documentation entry for a newly added
option in GCC 10.
Ready for trunk?
I thought this would be OK, until I saw:
+Enabled by default.
At the beginning of invoke.texi where it i
> PR ipa/69678
> * cgraph.c (symbol_table::create_edge): Init speculative_id.
> (cgraph_edge::make_speculative): Add param for setting speculative_id.
> (cgraph_edge::speculative_call_info): Find reference by
> speculative_id for multiple indirect targets.
> (cgr
On 11/13/19 8:23 PM, Jeff Law wrote:
On 11/13/19 2:37 AM, Martin Liška wrote:
As Nick also mentioned many times, -grecord-gcc-switches is in DWARF
and this causes a great disadvantage: it gets stripped out.
Well, that's still something I disagree. I bet RedHat is similarly to
openSUSE also bu
Bootstrapped and regtested on x86_64-redhat-linux, s390x-redhat-linux and
ppc64le-redhat-linux. OK for trunk and gcc-9-branch? I'd like to commit
this and https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00919.html together
to gcc-9-branch.
This is a follow-up to
https://gcc.gnu.org/ml/gcc-patches
On 11/5/19 1:38 PM, Richard Biener wrote:
On Mon, Nov 4, 2019 at 3:49 PM Jakub Jelinek wrote:
On Mon, Nov 04, 2019 at 03:23:20PM +0100, Martin Liška wrote:
The patch adds a new pass that identifies a series of if-elseif
statements and transform then into a GIMPLE switch (if possible).
The pas
On 11/6/19 10:02 PM, Bernhard Reutner-Fischer wrote:
Also why do you punt on duplicate conditions like in
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-4.c
+int main(int argc, char **argv)
+{
+ if (argc == 1)
+ else if (argc == 2)
+ else if (argc == 3)
+ else if (argc == 4)
+ else if (a
On 11/13/19 4:43 PM, Michael Matz wrote:
Hi,
On Wed, 13 Nov 2019, Martin Liška wrote:
Not a review, just a few questions:
Hello.
Thank you for it.
1) what does it do if __builtin_expect* has been used, does it preserve
the probabilities and if in the end decides to expand as ifs, ar
I've put the implementation into config/arm/aarch-common.c, so
that it can be shared between the two targets. This required
a little bit of cleanup to the CC modes and constraints to get
the two targets to match up.
Changes for v2:
* Document overflow flags.
* Add "hs" and "lo" as aliases of
The existing definition using register class CC_REG does not
work because CC_REGNUM does not support normal modes, and so
fails to match register_operand. Use a non-register constraint
and the cc_register predicate instead.
* config/arm/constraints.md (c): Use cc_register predicate.
---
Mirror arm in letting "c" match the condition code register.
* config/aarch64/constraints.md (c): New constraint.
---
gcc/config/aarch64/constraints.md | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/config/aarch64/constraints.md
b/gcc/config/aarch64/constraints.md
index d0c3
CC_NZmode is a more accurate description of what we require
from the mode, and matches up with the definition in aarch64.
Rename noov_comparison_operator to nz_comparison_operator
in order to match.
* config/arm/arm-modes.def (CC_NZ): Rename from CC_NOOV.
* config/arm/predicates.m
Since all but a couple of lines is shared between the two targets,
enable them both at once.
* config/arm/aarch-common-protos.h (arm_md_asm_adjust): Declare.
* config/arm/aarch-common.c (arm_md_asm_adjust): New.
* config/arm/arm-c.c (arm_cpu_builtins): Define
__GCC_
Inspired by the tests in gcc.target/i386. Testing code generation,
diagnostics, and execution.
* gcc.target/arm/asm-flag-1.c: New test.
* gcc.target/arm/asm-flag-3.c: New test.
* gcc.target/arm/asm-flag-5.c: New test.
* gcc.target/arm/asm-flag-6.c: New test.
---
g
Inspired by the tests in gcc.target/i386. Testing code generation,
diagnostics, and execution.
* gcc.target/aarch64/asm-flag-1.c: New test.
* gcc.target/aarch64/asm-flag-3.c: New test.
* gcc.target/aarch64/asm-flag-5.c: New test.
* gcc.target/aarch64/asm-flag-6.c:
On Thu, 14 Nov 2019, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on x86_64-redhat-linux, s390x-redhat-linux and
> ppc64le-redhat-linux. OK for trunk and gcc-9-branch? I'd like to commit
> this and https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00919.html together
> to gcc-9-branch.
OK.
On Thu, Nov 14, 2019 at 10:39 AM Martin Liška wrote:
>
> On 11/5/19 1:38 PM, Richard Biener wrote:
> > On Mon, Nov 4, 2019 at 3:49 PM Jakub Jelinek wrote:
> >>
> >> On Mon, Nov 04, 2019 at 03:23:20PM +0100, Martin Liška wrote:
> >>> The patch adds a new pass that identifies a series of if-elseif
Hello,
This is the first of a series of patches evolving the VxWorks
support in the compiler.
This particular change prepares the grounds for an evolution of the
VxWorks 7 support towards the more recent major upgrade of the base OS,
from the SR5xx to the SR6xx series in vendor parlance.
The OS
Hi,
On Wed, Nov 13 2019, Jan Hubicka wrote:
> Hi,
> the testcase causes inline context cache to go out of sync because I
> forgot to update used flags of parameters in one path of
> update_indirect_edges_after_inlining.
>
> While debugging it I also added better consistency check to
> ipa-inline-a
Hi!
In context of reviewing Julian's "OpenACC reference count overhaul", I'm
generally reviewing (also known as: trying to understand) the libgomp
OpenMP 'target' "refcount"ing , and I noticed something strange (?):
On 2015-07-30T22:44:33+0300, Ilya Verbin wrote:
> make check-target-libgomp pass
Hi,
tested x86_64-linux.
Thanks, Paolo.
///
/cp
2019-11-14 Paolo Carlini
* typeck.c (cp_build_addr_expr_1): Use cp_expr_loc_or_input_loc
in three places.
(lvalue_or_else): Use it in one place.
/testsuite
2019-11-14 Paolo Carlini
* g+
This is the second patch of the first set evolving the
VxWorks support before we move on to more c++ specific
capabilities.
This change generalizes a mechanism we have been using in a
ad-hoc manner for Ada for quite a while now, so C++ can also
benefit from it.
The general idea is to introduce Vx
On Thu, Nov 14, 2019 at 12:08:45PM +0100, Thomas Schwinge wrote:
> > @@ -794,7 +807,7 @@ gomp_offload_image_to_device (struct gomp_device_descr
> > *devicep,
> >/* Insert host-target address mapping into splay tree. */
> >struct target_mem_desc *tgt = gomp_malloc (sizeof (*tgt));
> >t
Hello,
This change adds support for the __GTHREAD_HAS_COND and __GTHREADS_CXX0X
facilities on top of what was already there for the base __GTHREADS code
on VxWorks. It also improves the general support to handle VxWorks 7 in
more configurations.
Split the current vxlib.c source into separate file
Hello,
This change first fixes a glitch in the VxWorks AE/653 configuration
settings, missing a Makefile fragment to pass the expected compilation
flags when building libgcc.
It also adds a t-gthr-vxworksae fragment for the
gthreads support, specialized from other variants as we
we haven't implem
> Hi,
>
> On Wed, Nov 13 2019, Jan Hubicka wrote:
> > Hi,
> > the testcase causes inline context cache to go out of sync because I
> > forgot to update used flags of parameters in one path of
> > update_indirect_edges_after_inlining.
> >
> > While debugging it I also added better consistency check
On Thu, Nov 14, 2019 at 09:45:28AM +0300, Konstantin Kharlamov wrote:
> On Ср, ноя 13, 2019 at 15:23, Jason Merrill
> wrote:
> >On Wed, Nov 13, 2019 at 6:39 AM Segher Boessenkool
> > wrote:
> >> There are users. There are users who have been used to this
> >>behaviour
> >> for many many many y
On Thu, 14 Nov 2019 12:08:45 +0100
Thomas Schwinge wrote:
> Hi!
>
> In context of reviewing Julian's "OpenACC reference count overhaul",
> I'm generally reviewing (also known as: trying to understand) the
> libgomp OpenMP 'target' "refcount"ing , and I noticed something
> strange (?):
>
> On 20
On 11/13/19 2:36 PM, Richard Biener wrote:
Hmm, can you please - as exercise - add Optimization only for
the "formerly" _o2 params you remove in the other patch to see
if with this you indeed get at a NOP effect?
Sure, there's a patch that removed max-inline-insns-auto-O2.
Patch can bootstrap o
Hi.
The patch is a clean up of unused code.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install the patch.
Thanks,
Martin
gcc/ChangeLog:
2019-11-14 Martin Liska
* tree-switch-conversion.c (switch_conversion::switch_conversion):
Do no
On Thu, Nov 14, 2019 at 1:00 PM Martin Liška wrote:
>
> On 11/13/19 2:36 PM, Richard Biener wrote:
> > Hmm, can you please - as exercise - add Optimization only for
> > the "formerly" _o2 params you remove in the other patch to see
> > if with this you indeed get at a NOP effect?
>
> Sure, there's
Hi.
As mentioned in the PR, the patch adds one more late pass_convert_switch
just before switch lowering.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-11-13 Martin Liska
PR tree-optimization/92005
On Thu, Nov 14, 2019 at 1:06 PM Martin Liška wrote:
>
> Hi.
>
> As mentioned in the PR, the patch adds one more late pass_convert_switch
> just before switch lowering.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
Hmm. I was thinking of mov
On Tue, Nov 12, 2019 at 11:35 AM Hongtao Liu wrote:
>
> Hi:
> As mentioned in https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00832.html
> > So yes, it's poorly named. A preparatory patch to clean this up
> > (and maybe split it into TARGET_AVX256_SPLIT_REGS and TARGET_AVX128_OPTIMAL)
> > would b
On Tue, Nov 5, 2019 at 3:09 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Oct 29, 2019 at 6:05 PM Richard Sandiford
> > wrote:
> >>
> >> The BB vectoriser picked vector types in the same way as the loop
> >> vectoriser: it picked a vector mode/size for the region and then
>
Hello,
This change introduces VxWorks support for aarch64, which
we have tested in-house through a number of C/Ada testsuite runs
for a mix of kernel and RTP configurations, with both gcc-8 and
gcc-9 based toolchains.
VxWorks uses r18 to hold a pointer to the current task TCB, which
conflicts wit
On Tue, Nov 5, 2019 at 9:45 PM Richard Sandiford
wrote:
>
> This patch makes can_duplicate_and_interleave_p cope with mixtures of
> vector sizes, by using queries based on get_vectype_for_scalar_type
> instead of directly querying GET_MODE_SIZE (vinfo->vector_mode).
>
> int_mode_for_size is now th
On 11/13/19 9:03 PM, Jeff Law wrote:
> OK. I'd actually recommend this go ahead and get installed. My tester
> will bootstrap it overnight.
Alright, let me know how that turns out. What kind of machine do you
have for that?
Bernd
On Thu, Nov 14 2019, Jan Hubicka wrote:
>> On Wed, Nov 13 2019, Jan Hubicka wrote:
>> > Hi,
>> > the testcase causes inline context cache to go out of sync because I
>> > forgot to update used flags of parameters in one path of
>> > update_indirect_edges_after_inlining.
>> >
>> > While debugging it
On Fri, Nov 8, 2019 at 3:35 AM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
> Thanks for the review.
>
> On Tue, 5 Nov 2019 at 23:08, Richard Biener
> wrote:
> >
> > On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah
> > wrote:
> > >
> > > Hi,
> > > Thanks for the review.
> > >
> > > On Tu
Hello,
This change replaces uses of CPU by uses of _VX_CPU in
TARGET_OS_CPP_BUILTINS for arm-vxworks, as the latter form is
more widely recognized across VxWorks versions.
It also adds a case for armv8, supported by at least
recent versions of VxWorks 7.
Tested in house with builds and various t
On Thu, 14 Nov 2019 10:41:25 +0100
Martin Liška wrote:
> On 11/6/19 10:02 PM, Bernhard Reutner-Fischer wrote:
> > Also why do you punt on duplicate conditions like in
> >
> >> +++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-4.c
> >> +int main(int argc, char **argv)
> >> +{
> >> + if (argc ==
Hello
Currently, when choosing a spill register, GCC just picks the first
available register in the register class returned by the
TAQRGET_SPILL_CLASS hook that doesn't conflict.
On AMD GCN this can cause problems as DImode values stored in SGPRs must
start on an even register number and TIm
A follow-up to previous post. The 1st patch was approved Jeff Law given
changelog is fixed. The second one is a compromise that came up in
discussion to the previous patchset.
Please add me to CC when replying, I'm not subscribed to the list.
Konstantin Kharlamov (2):
gdbinit.in: call a functio
Calling a function foo in gdb as "set foo()" results in a warning.
Disregarding, it looks wrong to call a function with "set". Let's use
"call" instead.
2019-11-14 Konstantin Kharlamov
* gdbinit.in (pr, prl, pt, pct, pgg, pgq, pgs, pge, pmz, pdd, pbs, pbm):
Use "call" instead o
Generally, people expect functions to accept arguments directly. But
ones defined in gdbinit did not use the argument, which may be confusing
for newcomers. But we can't change behavior to use the argument without
breaking existing users of the gdbinit. Let's fix this by adding a check
for whether
Hi,
this patch bumps inline-insns-single-O2 from 30 to 70. I originally reduced
it from 120 to 50 when forking the -O2 and -O3 parameters which has
quite significant code size benefits.
This parameter controls how large functions user declared inline are inlined
(sadly we really can't inline all)
Hello,
The pre VxWorks 7 ports are now obsolete, as pre VxWorks 7
on ARM rely on the long deprecated APCS ABI. VxWorks 7,
post SR600, is now llvm based and always uses ARM unwinding.
This change updates the GCC support accordingly, tightening
the set of accepted triplets from config.gcc to vx7 va
Hello
This patch fixes an issue seen in the following test cases on AMD GCN:
libgomp.oacc-fortran/gemm.f90
libgomp.oacc-fortran/gemm-2.f90
libgomp.c/for-5-test_ttdpfs_ds128_auto.c
libgomp.c/for-5-test_ttdpfs_ds128_guided32.c
libgomp.c/for-5-test_ttdpfs_ds128_runtime.c
libgomp.c/for-5-test_ttdpfs
Jakub Jelinek writes:
> On Wed, Nov 13, 2019 at 08:44:31AM +, Richard Sandiford wrote:
>> PR c++/92206
>> * g++.dg/cpp0x/alias-decl-pr92206-1.C: New test.
>> * g++.dg/cpp0x/alias-decl-pr92206-2.C: Likewise.
>> * g++.dg/cpp0x/alias-decl-pr92206-3.C: Likewise.
>
> This last t
On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
> Generally, people expect functions to accept arguments directly. But
> ones defined in gdbinit did not use the argument, which may be confusing
> for newcomers. But we can't change behavior to use the argument without
> breaking existing users of
On Thu, Nov 14, 2019 at 12:50:09PM +, Richard Sandiford wrote:
> > 2019-11-14 Jakub Jelinek
> >
> > * g++.dg/cpp0x/alias-decl-pr92206-3.C: Require effective target c++14
> > rather than c++11.
>
> Thanks, and sorry for the breakage. I obviously messed something up
> during the test
On Чт, ноя 14, 2019 at 15:55, Alexander Monakov
wrote:
On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
Generally, people expect functions to accept arguments directly. But
ones defined in gdbinit did not use the argument, which may be
confusing
for newcomers. But we can't change behav
On 11/14/19 10:07 AM, Richard Henderson wrote:
The existing definition using register class CC_REG does not
work because CC_REGNUM does not support normal modes, and so
fails to match register_operand. Use a non-register constraint
and the cc_register predicate instead.
* config/arm/c
Hi Richard,
On 11/14/19 10:07 AM, Richard Henderson wrote:
I've put the implementation into config/arm/aarch-common.c, so
that it can be shared between the two targets. This required
a little bit of cleanup to the CC modes and constraints to get
the two targets to match up.
Changes for v2:
*
On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
> Thanks! Unfortunately AFAIK ternary expressions are broken in gdb
> https://sourceware.org/bugzilla/show_bug.cgi?id=22466 :c
Indeed, I didn't notice that. But it still would be nice to avoid duplicating
the commands over and over again. Can we us
Hi,
On Mon, Nov 04 2019, Jan Hubicka wrote:
>> On 11/4/19 3:12 PM, Jan Hubicka wrote:
>> > Martin, do you know why this flag was introduced?
>>
>> Hi.
>>
>> The flag is used in IPA CP:
>>
>> call_summary
>>
>> class edge_clone_summary
>> {
>> ...
>> cgraph_edge *prev_clone;
>> cgraph_edge
On 14/11/2019 12:43, Kwok Cheung Yeung wrote:
Hello
This patch fixes an issue seen in the following test cases on AMD GCN:
libgomp.oacc-fortran/gemm.f90
libgomp.oacc-fortran/gemm-2.f90
libgomp.c/for-5-test_ttdpfs_ds128_auto.c
libgomp.c/for-5-test_ttdpfs_ds128_guided32.c
libgomp.c/for-5-test_ttd
Hi,
I think the patch generally looks reasonable
+2019-11-13 Feng Xue
+
+ PR ipa/92133
+ * doc/invoke.texi (ipa-cp-max-recursion-depth): Document new option.
+ * params.opt (ipa-cp-max-recursion-depth): New.
+ * ipa-cp.c (ipcp_lattice::add_value): Add two new parameters
+
On 11/14/19 2:07 PM, Kyrill Tkachov wrote:
>
> On 11/14/19 10:07 AM, Richard Henderson wrote:
>> The existing definition using register class CC_REG does not
>> work because CC_REGNUM does not support normal modes, and so
>> fails to match register_operand. Use a non-register constraint
>> and th
On Чт, ноя 14, 2019 at 16:13, Alexander Monakov
wrote:
On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
Thanks! Unfortunately AFAIK ternary expressions are broken in gdb
https://sourceware.org/bugzilla/show_bug.cgi?id=22466 :c
Indeed, I didn't notice that. But it still would be nice to
Hi,
On Mon, Nov 04 2019, Jan Hubicka wrote:
> Hi,
> I am not really pround of this implementation (and will think of better
> interface), but this patch saves about 10% of WPA time by avoiding
> unnecesary invalidations of the polymorphic call target hash during
> inlining.
>
> ipa-devirt register
> Hi,
>
> On Mon, Nov 04 2019, Jan Hubicka wrote:
> > Hi,
> > I am not really pround of this implementation (and will think of better
> > interface), but this patch saves about 10% of WPA time by avoiding
> > unnecesary invalidations of the polymorphic call target hash during
> > inlining.
> >
> >
On 11/14/19 2:08 PM, Kyrill Tkachov wrote:
> Hi Richard,
>
> On 11/14/19 10:07 AM, Richard Henderson wrote:
>> I've put the implementation into config/arm/aarch-common.c, so
>> that it can be shared between the two targets. This required
>> a little bit of cleanup to the CC modes and constraints
On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
> Though, this wouldn't be equivalent to what new people, who just want to call
> `debug()` with the arg, would expect :) If you want to deduplicate the
> function call, I can reorganize the code to be like this:
>
> define pp
> if ($argc == 0)
>
On Чт, ноя 14, 2019 at 16:57, Alexander Monakov
wrote:
On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
Though, this wouldn't be equivalent to what new people, who just
want to call
`debug()` with the arg, would expect :) If you want to deduplicate
the
function call, I can reorganize
On Nov 14 2019, Konstantin Kharlamov wrote:
> python (I dunno, I can ‾\_(ツ)_/‾). The code:
Python support is optional.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Hi,
This is a patch series to introduce the Armv8.1-M Mainline scalar shift
instructions to the arm backend.
Mihail Ionescu (2)
[PATCH, GCC/ARM, 1/2] Add support for ASRL(reg) and LSLL(reg) instructions for
Armv8.1-M Mainline
[PATCH, GCC/ARM, 2/2] Add support for ASRL(imm), LSLL(imm) and LSRL(i
Hi,
This patch adds the new scalar shift instructions for Armv8.1-M
Mainline to the arm backend.
This patch is adding the following instructions:
ASRL (reg)
LSLL (reg)
ChangeLog entry are as follow:
*** gcc/ChangeLog ***
2019-11-14 Mihail-Calin Ionescu
2019-11-14 Sudakshina Das
Hi,
This is part of a series of patches where I am trying to add new
instructions for Armv8.1-M Mainline to the arm backend.
This patch is adding the following instructions:
ASRL (imm)
LSLL (imm)
LSRL (imm)
ChangeLog entry are as follow:
*** gcc/ChangeLog ***
2019-11-14 Mihail-Calin Ionescu
On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
> I also named `dbgarg` as `debug_arg` because I figured I confuse whether it
> was `gdbarg` or `gdbarg` :D
It should begin with a dollar ($debug_arg), otherwise GDB will attempt to locate
and use a variable named 'debug_arg' in the program being d
Not had a chance to look at this in detail, but I don't see any support for
1) Thumb1 where we do not expose the condition codes at all
2) Thumb2 where we need IT instructions along-side the conditional
instructions themselves.
How have you tested this for those targets?
R.
On 14/11/2019 10:
On 14/11/2019 10:07, Richard Henderson wrote:
CC_NZmode is a more accurate description of what we require
from the mode, and matches up with the definition in aarch64.
Rename noov_comparison_operator to nz_comparison_operator
in order to match.
* config/arm/arm-modes.def (CC_NZ): Rename
On 14/11/2019 10:07, Richard Henderson wrote:
Inspired by the tests in gcc.target/i386. Testing code generation,
diagnostics, and execution.
* gcc.target/arm/asm-flag-1.c: New test.
* gcc.target/arm/asm-flag-3.c: New test.
* gcc.target/arm/asm-flag-5.c: New test.
On 14/11/2019 10:07, Richard Henderson wrote:
Since all but a couple of lines is shared between the two targets,
enable them both at once.
* config/arm/aarch-common-protos.h (arm_md_asm_adjust): Declare.
* config/arm/aarch-common.c (arm_md_asm_adjust): New.
* config/arm/a
On 11/13/19 8:35 PM, Jeff Law wrote:
> On 11/13/19 6:04 AM, Bernd Schmidt wrote:
>> The cc0 machinery allows for eliminating unnecessary comparisons by
>> examining the effect instructions have on the flags registers. I have
>> replicated that mechanism with a relatively modest amount of code based
On Thu, 14 Nov 2019, Alexander Monakov wrote:
> On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
>
> > I also named `dbgarg` as `debug_arg` because I figured I confuse whether it
> > was `gdbarg` or `gdbarg` :D
>
> It should begin with a dollar ($debug_arg), otherwise GDB will attempt to
> loca
On 11/14/19 3:39 PM, Richard Earnshaw (lists) wrote:
> Not had a chance to look at this in detail, but I don't see any support for
>
> 1) Thumb1 where we do not expose the condition codes at all
> 2) Thumb2 where we need IT instructions along-side the conditional
> instructions
> themselves.
>
>
On Чт, ноя 14, 2019 at 18:00, Alexander Monakov
wrote:
On Thu, 14 Nov 2019, Alexander Monakov wrote:
On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
> I also named `dbgarg` as `debug_arg` because I figured I confuse
whether it
> was `gdbarg` or `gdbarg` :D
It should begin with a d
On 11/14/19 3:48 PM, Richard Earnshaw (lists) wrote:
> On 14/11/2019 10:07, Richard Henderson wrote:
>> Since all but a couple of lines is shared between the two targets,
>> enable them both at once.
>>
>> * config/arm/aarch-common-protos.h (arm_md_asm_adjust): Declare.
>> * config/arm/aarc
Thanks for your review.
> In general the patch looks good to me, but I would like Martin Jambor to
> comment on the ipa-prop/cp interfaces. However...
> +@item ipa-cp-max-recursion-depth
> +Maximum depth of recursive cloning for self-recursive function.
> +
> ... I believe we will need more care
On 14/11/2019 15:06, Richard Henderson wrote:
On 11/14/19 3:39 PM, Richard Earnshaw (lists) wrote:
Not had a chance to look at this in detail, but I don't see any support for
1) Thumb1 where we do not expose the condition codes at all
2) Thumb2 where we need IT instructions along-side the condi
> Thanks for your review.
>
> > In general the patch looks good to me, but I would like Martin Jambor to
> > comment on the ipa-prop/cp interfaces. However...
>
> > +@item ipa-cp-max-recursion-depth
> > +Maximum depth of recursive cloning for self-recursive function.
> > +
>
> > ... I believe we
Hello
Although GCN has a large register file, these registers are distributed
among the threads (wavefronts) running on the same compute unit, so (up
to a point) the fewer registers used in a kernel, the more kernels can
run concurrently. While this is of limited use in trunk at the moment
wi
GCN 5 has commonly-used global memory instructions that specify the
address as [SGPR address] + [VGPR offset] + [constant offset], and we
often want the VGPR offset to be zero, so v0 is currently reserved for
that purpose.
However, v1 contains [0, 1, 2..., 63], and as we only use the first lan
The set of fixed registers is adjusted by the
TARGET_CONDITIONAL_REGISTER_USAGE hook, but this needs to be done on a
per-function basis, whereas the hook is normally called once during GCC
initialization before any functions have been processed (which means the
majority of the current implement
On Thu, 14 Nov 2019, Konstantin Kharlamov wrote:
> Haha, this is amazing! Will do. A newbish question: shall I send the updated
> patch "in reply" here, or should I resend the patchset?
Your choice, GCC doesn't have a hard rule for this. Personally I feel it's
more appropriate to send patches "i
This patch restricts non-kernel functions to using a maximum of 64 SGPRs
and 24 VGPRs.
Kernels can request various pieces of information from the HSA runtime,
and these will be loaded into the registers consecutively before the
kernel executes. These registers are normally fixed. Since non-ker
1 - 100 of 213 matches
Mail list logo
