on 2021/12/9 下午11:21, Martin Liška wrote:
> On 12/7/21 03:15, Kewen.Lin wrote:
>> Hi,
>>
>> For a function with optimize pragma, it's possible that the target
>> options change as optimization options change. Now we create one
>> optimization option node when parsing pragma optimize, but don't
>>
On December 12, 2021 9:35:00 PM GMT+01:00, Jan Hubicka via Gcc-patches
wrote:
>Hi,
>In evaluate_conditions_for_known_args we use range_fold_unary_expr and
>range_fold_binary_expr to produce value ranges of the expression.
>However the expression also may contain ternary COND_EXPR on which we
on 2021/12/9 上午9:43, Jeff Law wrote:
>
>
> On 12/6/2021 7:15 PM, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> For a function with optimize pragma, it's possible that the target
>> options change as optimization options change. Now we create one
>> optimization option node when parsing pragma
Add specialized version to combine two instructions from
9: {r123:CC=cmp(r124:DI&0x6,0);clobber scratch;}
REG_DEAD r124:DI
10: pc={(r123:CC==0)?L15:pc}
REG_DEAD r123:CC
to:
10: {pc={(r123:DI&0x6==0)?L15:pc};clobber scratch;clobber %0:CC;}
then split2 will split
Hi,
This patch defines a new split pattern for TI to V1TI move. The pattern
concatenates two subreg:DI of
a TI to a V2DI, then move the V2DI to V1TI. With the pattern, the subreg pass
can do register split for
TI when there is a TI to V1TI move. The patch optimizes one unnecessary "mr"
out
Also, the LIBGCCJIT_ABI_17 will need to be updated as I merged some of
my patches.
Le samedi 11 décembre 2021 à 15:35 +, Petter Tomner a écrit :
> Hi!
>
> > s/an union/a union/
> > s/a rvalue/an rvalue/
>
> Heh no way ... and I though I knew English grammar :)
>
> Had to look that up to
One thing I'm not sure if it is a code style issue, but worth
mentionning:
> @@ -1405,8 +1436,10 @@ private:
>
> private:
>enum gcc_jit_global_kind m_kind;
> + enum global_var_flags flags = GLOBAL_VAR_FLAGS_NONE;
^
Should it be named m_flags instead of
Yes, this patch works for rustc_codegen_gcc perfectly.
It even fixes one issue that was in my patch, so that's nice!
Le samedi 11 décembre 2021 à 15:35 +, Petter Tomner a écrit :
> Hi!
>
> > s/an union/a union/
> > s/a rvalue/an rvalue/
>
> Heh no way ... and I though I knew English grammar
On Fri, 3 Dec 2021 at 22:38, Jonathan Wakely wrote:
>
> On Mon, 22 Nov 2021 at 16:31, Stephan Bergmann via Libstdc++
> wrote:
> >
> > When using recent libstc++ trunk with Clang in C++20 mode,
> > std::u16string literals as in
> >
> > > #include
> > > int main() {
> > > using namespace
On 12/10/21 14:12, Patrick Palka wrote:
We use processing_template_decl in two slightly different ways: as
a flag to signal that we're dealing with templated trees, and its
magnitude is also used as a proxy for the current syntactic template
depth. This overloaded meaning of p_t_d is
Hi,
In evaluate_conditions_for_known_args we use range_fold_unary_expr and
range_fold_binary_expr to produce value ranges of the expression.
However the expression also may contain ternary COND_EXPR on which we
ICE. I did not find interface to do similar folding easily on ternary
exprs and since
>
> I think this is common pattern in C++ code originating from cast with
> multiple inheritance. I would vote towards optimizing out the conditial
> move in this case and I think it is correct.
I crafted a testcse and filled in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103674
Honza
>
>
>
>
> On 12/12/2021 3:49 AM, Jan Hubicka via Gcc-patches wrote:
> > Hi,
> > As discussed in the PR, we miss some optimization becuase
> > gimple-ssa-isolate-paths turns NULL memory accesses to volatile and adds
> > __builtin_trap after them. This is seen as a side-effect by IPA analysis
> > and
On 12/12/21 5:08 PM, Tobias Burnus wrote:
> I want to WITHDRAW that patch.
>
> I should read _emails_ before acting on _commit_ logs ...
>
heh :)
> Reason is given by Tom at:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586649.html
>
> However, we still shouldn't forget to update
The fix obvious: while the clause is 'allocate',
the 'allocate-modifiers' are 'allocator' (not 'allocate')
and 'align'.
Cf. https://www.openmp.org/spec-html/5.1/openmpsu63.html#x90-102.13.4
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
I want to WITHDRAW that patch.
I should read _emails_ before acting on _commit_ logs ...
Reason is given by Tom at:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586649.html
However, we still shouldn't forget to update *.texi and t-omp-device
eventually.
Tobias
On 12.12.21 17:01,
On 12/12/2021 3:49 AM, Jan Hubicka via Gcc-patches wrote:
Hi,
As discussed in the PR, we miss some optimization becuase
gimple-ssa-isolate-paths turns NULL memory accesses to volatile and adds
__builtin_trap after them. This is seen as a side-effect by IPA analysis
and additionally the
Hi Tom,
this documents the new sm_35 value to -misa=, which Roger added
(and uses for _Float16).
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank
> On December 12, 2021 1:22:09 PM GMT+01:00, Jan Hubicka via Gcc-patches
> wrote:
> >Hi,
> >ipa-modref is using TBAA to disambiguate memory accesses inter-procedurally.
> >This sometimes breaks programs with TBAA violations including clang with LTO.
> >To workaround that one can use
> >+ /* NULL memory accesses terminates BB. These accesses are known
> >+ to trip undefined behaviour. gimple-ssa-isolate-paths turns them
> >+ to volatile accesses and adds builtin_trap call which would
> >+ confuse us otherwise. */
> >+ if
On Sun, Dec 12, 2021 at 4:34 AM Richard Biener via Gcc-patches
wrote:
>
> On December 12, 2021 11:49:12 AM GMT+01:00, Jan Hubicka via Gcc-patches
> wrote:
> >Hi,
> >As discussed in the PR, we miss some optimization becuase
> >gimple-ssa-isolate-paths turns NULL memory accesses to volatile and
On December 12, 2021 1:22:09 PM GMT+01:00, Jan Hubicka via Gcc-patches
wrote:
>Hi,
>ipa-modref is using TBAA to disambiguate memory accesses inter-procedurally.
>This sometimes breaks programs with TBAA violations including clang with LTO.
>To workaround that one can use -fno-strict-aliasing or
On December 12, 2021 11:49:12 AM GMT+01:00, Jan Hubicka via Gcc-patches
wrote:
>Hi,
>As discussed in the PR, we miss some optimization becuase
>gimple-ssa-isolate-paths turns NULL memory accesses to volatile and adds
>__builtin_trap after them. This is seen as a side-effect by IPA analysis
>and
On 9/17/21 10:24 AM, Tobias Burnus wrote:
> Hi Roger,
>
> some more generic remarks not specific to using new ISA features.
>
> On 17.09.21 00:53, Roger Sayle wrote:
>
>> Whilst there I also added -misa=sm_75 and -misa=sm_80 which are points
>> where other useful instructions were added to the
Hi,
ipa-modref is using TBAA to disambiguate memory accesses inter-procedurally.
This sometimes breaks programs with TBAA violations including clang with LTO.
To workaround that one can use -fno-strict-aliasing or -fno-ipa-modref which
are both quite big hammers. So I added -fipa-strict-aliasing
Pushed to the branch.
Generate config.h macros for IEEE128 math functions.
libgfortran/ChangeLog:
* acinclude.m4 (LIBGFOR_CHECK_MATH_IEEE128): New macro.
* configure.ac: Use it.
* config.h.in: Regenerate.
* configure: Regenerate.
diff --git
Hi,
As discussed in the PR, we miss some optimization becuase
gimple-ssa-isolate-paths turns NULL memory accesses to volatile and adds
__builtin_trap after them. This is seen as a side-effect by IPA analysis
and additionally the (fully unreachable) builtin_trap is believed to load
all global
Hello.
I propose to make that message more verbose. It sure would have helped
me once. You don't always have a Web search available :)
Andrea Monaco
diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 4ded1760705..8b67662390e 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@
Hi,
As discussed in PR103585, fatigue2 is now only benchmark from my usual testing
set (SPEC2k6, SPEC2k17, CPP benchmarks, polyhedron, Firefox, clang) which sees
important regression when inlining functions called once is limited. This
prevents us from solving runtime issues in roms benchmarks
29 matches
Mail list logo
