On Mon, 17 Jun 2019, Tom de Vries wrote:
> Hi Alexander,
>
> any comments?
A couple suggestions (see below), but no serious concerns from my side.
> --- a/gcc/config/nvptx/nvptx.c
> +++ b/gcc/config/nvptx/nvptx.c
> @@ -112,6 +112,17 @@ enum nvptx_data_area
>DATA_AREA_MAX
> };
>
> +rtx
>
On Fri, 17 May 2019, Jeff Law wrote:
> So my question is are these showing up in practice? The gimple based
> tests seem to be skipping the optimizers that would have eliminated this
> stuff.
>
> In each of the testcases I would have expected jump threading to have
> eliminated the problematical
Hi,
this fixes PR 88879 by mostly restoring the previous behavior (accepting
negative priority values).
Approved by Andrey off-list, applying.
PR rtl-optimization/88879
* sel-sched.c (sel_target_adjust_priority): Remove assert.
Index: sel-sched.c
On Fri, 26 Apr 2019, Martin Liška wrote:
> I'm suggesting to adjust that to:
> - -Os will keep using rep-scasb as -Os means optimize for size
> no matter what speed impact is
I'm not sure it's a good choice, the inline sequence is
xorl%eax, %eax
orq $-1, %rcx
rep
On Fri, 12 Apr 2019, Jeff Law wrote:
> We've been through the "who owns the argument slots, caller or callee"
> discussion a few times and I don't think we've ever reached any kind of
> conclusion in the general case.
Callee must own the slots for tail calls to be possible.
> I think this case si
Hi,
this patch by Andrey fixes iteration in get_all_loop_headers where we want to
visit only inner loops, not the outer loop.
Alexander
2019-04-02 Andrey Belevantsev
PR rtl-optimization/84206
* sel-sched-ir.h (get_all_loop_exits): Avoid the outer loop when
iterating o
Hi,
this patch by Andrey adjusts reset of first_insn in code_motion_path_driver in
order to avoid taking it from before the original insn.
Alexander
2019-04-02 Andrey Belevantsev
PR rtl-optimization/85876
* sel-sched.c (code_motion_path_driver): Avoid unwinding first_insn
PR 89916 points out that the new test fails when -m32 is not supported, and
I see other tests don't try to add -m32, so I'm removing it.
PR testsuite/89916
* gcc.dg/pr86928.c: Do not attempt to add -m32.
--- testsuite/gcc.dg/pr86928.c (revision 270061)
+++ testsuite/gcc.dg/pr8692
Hi,
this patch by Andrey moves an assignment to reset_sched_cycles_p
after rev. 259228 placed it incorrectly.
2019-04-01 Andrey Belevantsev
PR rtl-optimization/85412
* sel-sched.c (sel_sched_region): Assign reset_sched_cycles_p before
sel_sched_region_1, not after.
Hi,
This patch by Andrey fixes PR 86928 by avoiding leaving basic blocks without
computed liveness info.
2019-04-01 Andrey Belevantsev
PR rtl-optimization/86928
* sel-sched-ir.c (sel_redirect_edge_and_branch_force): Invoke
compute_live if necessary.
(sel_redire
Hi,
I'm applying this patch on Andrey's behalf to resolve PR 87273 where an
overly strict assert fires; Andrey explanation in PR comment #5 provides
more detail.
Alexander
2019-04-01 Andrey Belevantsev
PR rtl-optimization/87273
* sel-sched-ir.c (merge_fences): Remove assert.
myself.
--- MAINTAINERS (revision 269710)
+++ MAINTAINERS (working copy)
@@ -293,6 +293,7 @@
register allocationSeongbae Park
RTL optimizers Steven Bosscher
selective scheduling Andrey Belevantsev
+selective scheduling Alexander Monakov
wide-int
On Fri, 15 Mar 2019, Jakub Jelinek wrote:
> On Fri, Mar 15, 2019 at 01:25:57PM +0300, Andrey Belevantsev wrote:
> > As explained in the PR trail, we incorrectly update the availability sets
> > in the rare case of several successors and one of them having another
> > fence. Fixed as follows. Ok
On Mon, 11 Mar 2019, Jakub Jelinek wrote:
> On Mon, Mar 11, 2019 at 02:25:59PM +0100, Martin Liška wrote:
> > @@ -38375,7 +38375,7 @@ rdseed_step:
> >mode0 = insn_data[icode].operand[0].mode;
> >if (!insn_data[icode].operand[0].predicate (op0, mode0))
> > {
> > - error ("
On Thu, 28 Feb 2019, Alexander Monakov wrote:
> Hi,
>
> in PR 85899 an assert is failing in find_fallthru_edge_from because the code
> tries to verify the invariant e->dest == e->src->next_bb for a fallthru edge
> and does not anticipate that it will fail if e->d
Hi,
in PR 85899 an assert is failing in find_fallthru_edge_from because the code
tries to verify the invariant e->dest == e->src->next_bb for a fallthru edge
and does not anticipate that it will fail if e->dest is the exit block (bb 1):
in this case next_bb is fairly arbitrary (it's just the next
Hi,
df_mw_compare tries to order df_mw_hardreg structures lexicographically, but
the last comparison step wrongly tests one field (mw_reg) while subtracting
another (mw_order). This makes the comparison non-transitive.
Fix this by simply returning difference of mw_order.
Patch pre-approved by R
On Mon, 18 Feb 2019, Aaron Sawdey wrote:
> The code in emit_case_dispatch_table() will very clearly always emit
> branch/label/jumptable_data/barrier
> so this does need to be handled. So, yes tablejump always looks like this,
> and also yes it seems to be
> ripe ground for logic bugs, we have 8
On Mon, 11 Feb 2019, Wilco Dijkstra wrote:
> > With Gold linker this is handled correctly. So it looks to me like a
> > bug in BFD linker, where it ignores any addend (not just +1/-1) when
> > resolving a relocation against a Thumb function.
>
> If the Gold linker doesn't fail that means Gold has
On Mon, 11 Feb 2019, Wilco Dijkstra wrote:
> The GCC optimizer can generate symbols with non-zero offset from simple
> if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations
> with offsets fail if it changes bit zero and the relocation forces bit zero
> to true. The fix is to
On Mon, 21 Jan 2019, Alexander Monakov wrote:
> Ah, I see now. I agree transparent_union ought to work, but today both GCC
> and Clang will reject such attempt; I've filed PR 88955 for the GCC issue.
>
> So unfortunately such code would still need a cast or an unnamed temporar
On Wed, 23 Jan 2019, Alexander Monakov wrote:
> It appears that sched-deps tries to take notice of a barrier after a jump, but
> similarly to sched-ebb doesn't anticipate that for a tablejump the barrier
> will
> appear after two more insns (a code_label and a jump_table_data
On Wed, 23 Jan 2019, Alexander Monakov wrote:
> That said, I'm really concerned that on this testcase we should not be moving
> the tablejump *at all*: we are moving it up past a 'use ax' insn (the use is
> for the function's return value). So after the move th
On Wed, 23 Jan 2019, Andrey Belevantsev wrote:
> For that, I'm not sure. Your patch will leave the tablejump unscheduled at
> all, i.e. any fields like INSN_TICK would be unfilled and thus the later
> passes like bundling on ia64 will not work. Maybe we can just stop
> tablejumps from moving wit
On Mon, 21 Jan 2019, Richard Biener wrote:
> > Sorry, I don't see what you mean here; can you give an example or elaborate?
>
> when you call a function with v4si signature but want to pass it a result
> from a __mm intrinsic you'd need a temporary union to do the marshalling.
> I think you can u
On Mon, 21 Jan 2019, Richard Biener wrote:
> I'm not sure whether it's permitted to use this in C++ or not (and whether
> the C usage is now officially sanctioned other than via a non-normative
> footnote) - but at least GCC will guarantee that it works.
My impression is that, via the "active mem
Hi,
PR 88698 ("Relax generic vector conversions") is asking to be more permissive
about type compatibility for generic vector types. While I don't think that's
a good idea per se, from a "compiler user" point of view I also see how writing
code for SSE/AVX using both generic vectors and x86 intri
On Thu, 3 Jan 2019, Johannes Pfau wrote:
>
> Debugging shows that the access function used to check
> if the input files exist has different behavior in newer msvcr libraries:
> It does return proper results for the 'nul' file in the old msvcrt.dll
> but in newer libraries it returns EINVAL for th
On Fri, 30 Nov 2018, Richard Biener wrote:
> > Ping - as I think this approach addresses the root of the problem, I
> > wouldn't
> > like it to be forgotten.
>
> I agree this is also useful but it addresses another issue (that may appear to
> be related). asm inline is really a hint to the inlin
> On Mon, 15 Oct 2018, Richard Biener wrote:
> > I think it's sound but also note that I think it is logically independent of
> > asm inline (). While it may work for the inlining issue for some kernel
> > examples to asm inline () is sth similar to always_inline for functions,
> > that is, even t
On Tue, 20 Nov 2018, Michael Matz wrote:
>
> I'm wondering about testcase: should I add an x86-64 specific that tests
> for no stack accesses, or would that be too constraining in the future?
>
> Regstrapped on x86-64-linux, no regressions. Okay for trunk?
By the way, this patch helps x86-64 o
On Fri, 16 Nov 2018, Michael Matz wrote:
> > This follows both your model
>
> Not really, it ignores the fact that 'a' can change at any time, which is
> what happens.
Are you saying that local register variables, in your model, are essentially
unfit for passing operands to inline asm on specifi
On Thu, 15 Nov 2018, Michael Matz wrote:
> I disagree that there's something to fix. My mental model for local reg
> vars has always been that such vars are actually an alias for that
> register, not comparable to normal automatic variables (so, much like
> global reg vars, except that they don
On Wed, 14 Nov 2018, Segher Boessenkool wrote:
> Yeah, using local register vars to access global registers only works
> by accident. It does work currently though, and people apparently use
> it, so we shouldn't break it :-/
In the proposed approach (copying from/to pseudos just before/after the
On Wed, 14 Nov 2018, Michael Matz wrote:
> Hi,
>
> it's not c++98 conforming and I get 1 million warnings when compiling.
> Initially I had also casts to long at the various arguments, but I get no
> warning with this variant either, so I removed them again. I'm currently
> regstrapping this
On Wed, 14 Nov 2018, Segher Boessenkool wrote:
> > I think with "=g" rather than "+g" this example is ok.
>
> No, it needs the register var as an input. That is the whole *point*.
Hm. I think I see what you meant, but "+g" is not correct either: the
asm, by intent, depends *on the current value
On Wed, 14 Nov 2018, Jakub Jelinek wrote:
> On Wed, Nov 14, 2018 at 06:22:51AM -0600, Segher Boessenkool wrote:
> > Btw, if you just add
> >
> > void *
> > retsp (void)
> > {
> > register void *sp __asm ("sp");
> > asm ("" : "+g" (sp)); // <-- this line
> > return sp;
> > }
> >
> > everyt
On Tue, 13 Nov 2018, Martin Sebor wrote:
> In PR 88000 the reporter expects to be able to use an explicit
> register local variable in a context where it isn't supported
> i.e., for something other than an input or output of an asm
> statement: namely to pass it as argument to a user-defined
> fun
On Mon, 15 Oct 2018, Richard Biener wrote:
> I think it's sound but also note that I think it is logically independent of
> asm inline (). While it may work for the inlining issue for some kernel
> examples to asm inline () is sth similar to always_inline for functions,
> that is, even though an a
On Tue, 30 Oct 2018, Martin Liška wrote:
> Hi.
>
> I'm going to install one obvious documentation fix as reported here:
> https://gcc.gnu.org/ml/gcc/2018-10/msg00252.html
>
> Martin
>
> gcc/ChangeLog:
>
> 2018-10-30 Martin Liska
>
> * doc/extend.texi: Fix typo in documentation
>
On Mon, 29 Oct 2018, Jason Merrill wrote:
> On Mon, Oct 29, 2018 at 7:07 AM Alexander Monakov wrote:
> > On Thu, 25 Oct 2018, Jason Merrill wrote:
> > > > >
> > > > > Maybe we should remove that in favor of fold_for_warn in
> > > > > check
On Mon, 29 Oct 2018, Martin Liška wrote:
> My question is whether we want to have in GCC 9 time frame or should I wait
> with that?
> Does it worth implementing?
This is cool, thanks! A few questions/comments on the patch.
I think there are places that use libiberty C-style hashtab (htab_t), wou
On Thu, 25 Oct 2018, Jason Merrill wrote:
> > >
> > > Maybe we should remove that in favor of fold_for_warn in
> > > check_function_arguments.
David, I think your patch also fixes PR 86567.
David, Jason, could you comment on doing something similar (using fold_for_warn
instead of maybe_constant_
On Mon, 22 Oct 2018, Martin Liška wrote:
> On 10/11/18 3:03 PM, Jakub Jelinek wrote:
> > On Thu, Oct 11, 2018 at 02:56:14PM +0200, Martin Liška wrote:
> >> As seen in the PR, switch conversion can do better when we return equal
> >> numbers
> >> based on index value. I implemented more than that,
On Mon, 15 Oct 2018, Segher Boessenkool wrote:
> On Sun, Oct 14, 2018 at 11:07:20PM +0300, Alexander Monakov wrote:
> > For Basic asms, no similar mechanism is necessary since they are
> > antithetical
> > to efficiency in the first place.
>
> I missed this part.
&g
On Mon, 15 Oct 2018, Robin Dapp wrote:
> * haifa-sched.c (priority): Add force_recompute parameter.
> (apply_replacement):
> Call priority () with force_recompute = true.
> (restore_pattern): Likewise.
A C++ style nit/question: instead of adding a new overload
priority
> > I think only double quote, backslash, backtick remain unclaimed. And of
> > course
> > ASCII \0 through \040 and \177 ;)
>
> I see. Apart from using some of the traditional begin-end sequences we
> could use %; or similar on each line to "comment" it?
I guess in theory we could define perce
On Mon, 15 Oct 2018, Jakub Jelinek wrote:
> On Mon, Oct 15, 2018 at 01:36:36PM +0300, Alexander Monakov wrote:
> > On Mon, 15 Oct 2018, Richard Biener wrote:
> > >
> > > Oh, and I personally find %` ugly ;) What non-alnum chars
> > > are taken by backends
On Mon, 15 Oct 2018, Richard Biener wrote:
>
> Oh, and I personally find %` ugly ;) What non-alnum chars
> are taken by backends?
I think only double quote, backslash, backtick remain unclaimed. And of course
ASCII \0 through \040 and \177 ;)
Alexander
On Sun, 14 Oct 2018, Uros Bizjak wrote:
> > +/* { dg-final { scan-assembler-times "punpcklqdq\[ \\t\]+%xmm\[0-9\],\[
> > \\t\]+%xmm\[0-9\]" 1 } } */
>
> You need to scan for %xmm\[0-9\]+, otherwise xmm10 is already out of luck.
I think it would be preferable to scan for 'punpcklqdq xmm0, xmm0' e
Hello,
This is an alternative proposal to the "asm inline" feature.
Kernel developers have reported suboptimal optimization where use of asm
statements such as
asm("ud2\n"
".pushsection foo\n"
...
".popsection\n" : : ...)
impacts inlining decisions badly, since GCC assumes c
On Sun, 14 Oct 2018, Alexander Monakov wrote:
>
> I doubt this is a correct fix, and I think the issue merits more
> investigation.
> Please see comment #5 in the PR.
Sorry, it seems I was misunderstanding how constraints interact with cost
calculation. I withdraw my objection
On Sat, 13 Oct 2018, H.J. Lu wrote:
> Add register source to movddup so that IRA will allow register source
> for *vec_dupv2di when SSE3 is enabled.
>
> gcc/
>
> PR target/87599
> * config/i386/sse.md (*vec_dupv2di): Add register source to
> movddup.
>
> gcc/testsuite/
>
>
On Fri, 12 Oct 2018, Segher Boessenkool wrote:
> > Please consider that as currently GCC over-estimates length of such asms,
> > branches around them are emitted as long-range jumps more often than needed,
> > which should be a problem we'd want to solve, because the whole reason this
> > is being
On Fri, 12 Oct 2018, Segher Boessenkool wrote:
> > For instance by introducing special tokens like %[ %] that demarkate
> > portion of the asm that shouldn't be counted:
>
> This potentially conflicts with targetm.asm_out.print_operand_punct_valid_p
> (and it does in fact conflict for microblaze).
On Fri, 12 Oct 2018, Segher Boessenkool wrote:
> The Linux kernel people want a feature that makes GCC pretend some
> inline assembler code is tiny (while it would think it is huge), so
> that such code will be inlined essentially always instead of
> essentially never.
I do apologize for being qu
On Thu, 11 Oct 2018, Martin Liška wrote:
> Hi.
>
> As seen in the PR, switch conversion can do better when we return equal
> numbers
> based on index value. I implemented more than that, more precisely I support
> all linear
> transformation based on index value. It's the same what clang is cap
Hello,
On Tue, 24 Jul 2018, tamar.christ...@arm.com wrote:
>
> * params.c (validate_param): New.
> (add_params): Use it.
> (set_param_value): Refactor param validation into validate_param.
> (diagnostic.h): Include.
> * diagnostic.h (diagnostic_ready_p): New.
this p
On Wed, 26 Sep 2018, Qing Zhao wrote:
> I don’t think a -Os-like option will do the job.
>
> As Jeff already mentioned in a very previous email:
>
> “Presumably one of the cases where this capability is really helpful is
> things like ksplice. If you have a function with global scope that has
>
On Wed, 26 Sep 2018, Qing Zhao wrote:
> The request is for application developers who want to use gcc's online
>patching feature.
>
> Today, developers can turn off inlining and deliver just the patched routine.
> They
>can also allow all inlining and deliver the patched routine and all
On Wed, 26 Sep 2018, Qing Zhao wrote:
> Alexander,
>
> thanks for the questions.
>
> Yes, we had some discussion on the questions you raised during the review of
> the initial patch back to 9/11/2018.
> please take a look at those discussions at:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-09/
On Fri, 21 Sep 2018, Qing Zhao wrote:
> +2018-09-20 Qing Zhao
> +
> + * cif-code.def (FUNCTION_EXTERN): New CIFCODE.
> + * common.opt (-finline-only-static): New option.
> + * doc/invoke.texi: Document -finline-only-static.
> + * ipa-inline.c (can_inline_edge_p): Control inlining
On Wed, 12 Sep 2018, Richard Biener wrote:
> With LTO "static" is too blurry - would -finline-only-hidden be OK
> with you?
This doesn't sound right - in non-pic, everything is hidden, effectively.
And the intended use is with Linux kernel, which does not use -fpic.
I agree with LTO this option m
On Wed, 12 Sep 2018, Martin Liška wrote:
> I see, I'm attaching patch that does that. I can confirm your test-case works
> fine w/o -Wl,--dynamic-list-data.
>
> I'm wondering if it will work as well with dlopen/dlsym machinery? Or now
> the linker flag will be needed?
No, for this issue dlopen do
On Tue, 11 Sep 2018, Qing Zhao wrote:
> no immediate use case for -finline-visibility=extern right now. But I guess
> that GCC developers might use this option to control inlining scope for
> debugging or development purpose in the future.
In that case I'd recommend to simplify the patch by implem
On Tue, 11 Sep 2018, Qing Zhao wrote:
> '-finline-visibility=[all|extern|static]'
> By default, GCC inlines functions without considering their
> visibility. This flag allows finer control of inlining based on
> their visibility.
>
> The value 'extern' tells the compiler to on
On Tue, 11 Sep 2018, Martin Liška wrote:
> I've discussed the topic with Alexander on the Cauldron and we hoped
> that the issue with unique __gcov_root can be handled with DECL_COMMON in
> each DSO.
> Apparently this approach does not work as all DSOs in an executable have
> eventually
> just a
On Wed, 29 Aug 2018, Alexander Monakov wrote:
> On Tue, 28 Aug 2018, Michael Matz wrote:
> > > I think it's not too complicated, but how about adding this comment:
> > >
> > > profile_count m = c1.max (c2);
> > > /* Return 0 if cou
On Fri, 31 Aug 2018, Kyrill Tkachov wrote:
> > That sounds good! Although I'm confused about what the 'p' means.
>
> It stands for "predicate" meaning a boolean function with no side-effects.
> It's the preferred way to name these kinds of functions in GCC (though I can't
> seem to find the docume
On Wed, 29 Aug 2018, Martin Liška wrote:
> > Can you shortly tell why the testcase in the PR segfaults? Does the issue
> > only affect indirect call profiling?
>
> What happens is that there will exist 2 instances of:
> void * __gcov_indirect_call_callee;
>
> one in main executable, and one anot
On Wed, 29 Aug 2018, Martin Liška wrote:
> >> That said, it looks the shared library libgcov.so is overkill.
> >
> > It feels like that somehow.
> >
> >> Alexander may explain how that can be beneficial?
> >>
> >> Note that I can fix the segfault being caused by inter-DSO calls.
> >
> > I think
On Tue, 28 Aug 2018, Michael Matz wrote:
> > I think it's not too complicated, but how about adding this comment:
> >
> > profile_count m = c1.max (c2);
> > /* Return 0 if counts are equal, -1 if E1 has the larger count. */
> > return (m == c2) - (m == c1);
> >
> > Or, alternatively, emplo
On Tue, 28 Aug 2018, Richard Biener wrote:
> I think that if we want to support MULT_HIGHPART generally then we need
> to support it for all modes - what's your plan for 32bit targets here? This
> means providing libgcc fallback implementations for modes we cannot directly
> expand to.
I didn't h
On Tue, 28 Aug 2018, Richard Biener wrote:
> On Tue, Aug 28, 2018 at 11:22 AM Alexander Monakov wrote:
> >
> > This converts the use in bb-reorder. I had to get a little bit creative
> > with
> > the comparator as profile_count::operator> does not implement a stri
Hi,
PR 86726 is pointing out that -ftree-scev-cprop is not documented.
Here's documentation for the final-value-replacement aspect of the
option. It technically can also replace in-loop references by
constants, but that doesn't seem very useful.
I'm not aware of any required order for option pa
This converts the use in bb-reorder. I had to get a little bit creative with
the comparator as profile_count::operator> does not implement a strict weak
order.
* gcc/bb-reorder.c (edge_order): Convert to C-qsort-style
tri-state comparator.
(reorder_basic_blocks_simple): Ch
This converts std::stable_sort use in tree-loop-distribution to gcc_stablesort.
* gcc/tree-loop-distribution.c (offset_cmp): Convert to C-qsort-style
tri-state comparator.
(fuse_memset_builtins): Change std::stable_sort to gcc_stablesort .
diff --git a/gcc/tree-loop-distr
This adds a stable sort to sort.cc: mergesort implementation is stable, so
we just need network sort limited to sizes 2-3 to get the complete sort stable.
As I don't want to duplicate code for this, I've chosen to have gcc_qsort
accept bit-inverted 'size' parameter to request stable sorting.
Hi,
This is an independently useful patch that makes it easier to introduce
gcc_stablesort.
Swap responsibilities of gcc_qsort and qsort_chk: call the checking function
from the sorting function instead of wrapping gcc_qsort with qsort_chk.
* gcc/sort.cc (gcc_qsort) [CHECKING_P]: Call qs
> > > So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if
> > > not supported?
Richard, how should we proceed from here? Do you like the solution in the
initial mail, or would you prefer something else? FWIW I agree with Pekka,
no need to burden BRIG FE with expanding mul-highp
Currently bootstrap stages 2 and 3 use the same warning options, but that is
redundant: if any warnings are generated, they will be present in stage 2 (and
stop bootstrap). By not enabling any warnings for stage 3, we would get
simple automated checking that warnings do not affect code generation.
Hello,
If patch 2/2 is approved, I'd like to apply this alongside with that.
Use positive form ("suppress") rather than negative ("don't") to explain
the option, because using the option results in passing -Wno-format
rather than not passing -Wformat. I felt confused when trying to follow
the l
Hello,
I'd like to apply this to resolve PR 85758. In bug discussion Marc noted that
what we are doing leads to code with higher instruction-level parallelism,
but it also has higher register pressure and longer code if the target does
not expose and-not patterns.
Now that we have 2->2 combine, i
On Mon, 20 Aug 2018, Iain Sandoe wrote:
> I am seeing excess changes when running configure, is it possible the
> regenerated files were missed from this rev?
>
> https://gcc.gnu.org/ml/gcc-cvs/2018-07/msg00172.html
Yes, that change did not regenerate configure scripts. I've also noticed th
On Mon, 20 Aug 2018, Richard Biener wrote:
> So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if
> not supported?
Pekka, can you comment? I think you have fallback paths for vector types
only at the moment?
Does BRIG have mult-highpart for 64-bit integers? On 32-bit targets we
Hello,
I'd like to apply the following patch to make GENERIC expressions
used in final value replacement visible in pass dumps.
We currently dump only the last statement, but that is not very
convenient as final values are sometimes complex and expand to
multiple gimple statements.
* tre
For testing generic expansion of MULT_HIGHPART_EXPR I chose to expose it
via the GIMPLE FE with the following patch.
"h*" is how tree-pretty-print dumps MULT_HIGHPART_EXPR.
This patch accepts "h*" which ideally shouldn't happen, but
I don't see a simple way to fix that.
Is this desirable for tru
Hello,
We currently have an unfortunate situation where, on the one hand, scalar
MULT_HIGHPART_EXPR is usable only if the backend provides the corresponding
pattern (otherwise ICEs in expand), but on the other hand, the BRIG frontend
wants to make use of it.
I think BRIG FE is making assumptions
Hello,
on x86-64, 32-bit division by constants uses mulsi3_highpart pattern that
turns into 'mull ' instruction with source implicitly in eax and
result in edx:eax. However, using 64-bit multiplication with zero-extended
source would be preferable, as the imulq instruction accepts the magic
multi
Hi,
when using explicit register variables ('register int foo asm("%ebp");'),
using const/volatile type qualifiers on the declaration does not result in
the logically expected effect.
The main issue is that gcc-8 got "better" at propagating initializers of
'register const' variables to their uses
Hi,
This adds Vim syntax highlighting rules for match.pd and packages them together
with gcc-rtl.vim and gimple.vim, creating contrib/vim-gcc-dev subtree that can
be installed as a common Vim plugin.
Thanks.
Alexander
* vim-gcc-dev/README: New file.
* vim-gcc-dev/ftdetect/gcc-dev
On Mon, 25 Jun 2018, Richard Biener wrote:
>> Sigh - I see GCC optimizes memmove as well as memcpy in this case, so
>> changing the offending memcpy calls to memmoves would be a bit cleaner. OK to
>> go with this instead?
>
> I think that's better. Or conditionalizing the offending ones on dest! =
On Mon, 25 Jun 2018, Alexander Monakov wrote:
>
> In PR 86311 Valgrind flags a call to memcpy with overlapping buffers. This can
> happen in reorder{23,45} helpers when we're reordering in-place, and the
> 3rd/5th
> element doesn't need to be moved: in that case th
Hi,
In PR 86311 Valgrind flags a call to memcpy with overlapping buffers. This can
happen in reorder{23,45} helpers when we're reordering in-place, and the 3rd/5th
element doesn't need to be moved: in that case the middle memcpy is called
with source == destination.
The fix is simple: just use a
On Fri, 15 Jun 2018, Martin Liška wrote:
> So you prefer to come up with a plugin folder with the *.vim files?
Yes, the main reason being very simple installation if already using a
plugin manager. A plugin folder may contain a custom ftdetect/foo.vim,
so there's no need to edit .vimrc by hand.
I
On Thu, 14 Jun 2018, Alexander Monakov wrote:
> However, it is not added to LTO streamed-out symtab, so WPA does not see it.
>
> If the direction looks fine overall, I'll look into getting over this
> streaming hurdle (hints much appreciated).
Well, going down this rabbit hole i
On Thu, 14 Jun 2018, David Malcolm wrote:
> The idea is to later use these macros to mark the
> if (dump_enabled_p ())
> parts of the compiler as cold, in the hope of helping non-PGO builds
> of gcc.
I think a cleaner way to achieve that would be to mark a function called
under the predicate wi
On Tue, 12 Jun 2018, Martin Liška wrote:
> This is equivalent of gimple.vim file. I'm aware of not full coverage of RTL
> instructions, but hope it's a good start point.
I think this is nice to have and hope you'll get an OK for both this and
the gimple.vim patch.
One nit-pick: unlike "GIMPLE",
On Thu, 14 Jun 2018, Richard Biener wrote:
> Can you make sure to add a testcase?
Apologies, I got a bit too excited and forgot that my local testcase had
void *unused_ref = &foo;
which masked another issue: unreferenced declarations won't even appear
in the symtab, even if they have __attri
Hello,
We have a somewhat long-recognized problem with LTO vs. symbols referenced
in inline asm statements. For extended asms, the solution is easy: just
mention the symbol in constraints. For toplevel asms, this is trickier, as
they cannot have constraints.
I think a good solution for toplevel a
301 - 400 of 1009 matches
Mail list logo
