On Wed, 2 Oct 2024, Jakub Jelinek wrote:
> Hi!
>
> In the Cauldron IPA/LTO BoF we've discussed toplevel asms and it was
> discussed it would be nice to tell the compiler something about what
> the toplevel asm does. Sure, I'm aware the kernel people said they
> aren't willing to use something
Tie together the two functions that ensure tail padding with
search_line_ssse3 via CPP_BUFFER_PADDING macro.
libcpp/ChangeLog:
* internal.h (CPP_BUFFER_PADDING): New macro; use it ...
* charset.cc (_cpp_convert_input): ...here, and ...
* files.cc (read_file_guts): ...here,
The recently introduced search_line_fast_ssse3 raised padding
requirement from 16 to 64, which was adjusted in read_file_guts,
but the corresponding ' + 16' in _cpp_convert_input was overlooked.
libcpp/ChangeLog:
PR preprocessor/116458
* charset.cc (_cpp_convert_input): Bump paddi
On Thu, 22 Aug 2024, Marc Poulhiès wrote:
> Single argument static_assert is C++17 only.
>
> libcpp/ChangeLog:
>
> * lex.cc: fix static_assert to use 2 arguments.
When pushing, please fix the entry to mention the function name if that's
not too much trouble:
* lex.cc (search_line
295,155 branch-misses:u #0.65% of all
branches ( +- 0.11% )
0.033242 +- 0.000418 seconds time elapsed ( +- 1.26% )
Is the revised patch below still ok? I've rolled the configury changes into it,
and dropped the (now unnecessary) AVX2 helper
On Wed, 7 Aug 2024, Richard Biener wrote:
> > > This is probably to work around bugs in older compiler versions? If
> > > not I agree.
> >
> > This is deliberate hand-tuning to avoid a subtle issue: pshufb is not
> > macro-fused on Intel, so with propagation it is two uops early in the
> > CPU
On Wed, 7 Aug 2024, Richard Biener wrote:
> > > + data = *(const v16qi_u *)s;
> > > + /* Prevent propagation into pshufb and pcmp as memory operand. */
> > > + __asm__ ("" : "+x" (data));
> >
> > It would probably make sense to a file a PR on this separately,
> > to eventually fi
On Wed, 7 Aug 2024, Richard Biener wrote:
> OK with that change.
>
> Did you think about a AVX512 version (possibly with 32 byte vectors)?
> In case there's a more efficient variant of pshufb/pmovmskb available
> there - possibly
> the load on the branch unit could be lessened with using maskin
On Tue, 6 Aug 2024, Alexander Monakov wrote:
> --- a/libcpp/files.cc
> +++ b/libcpp/files.cc
[...]
> + pad = HAVE_AVX2 ? 32 : 16;
This should have been
#ifdef HAVE_AVX2
pad = 32;
#else
pad = 16;
#endif
Alexander
Use the same PSHUFB-based matching as in the SSSE3 helper, just 2x
wider.
Directly use the new helper if __AVX2__ is defined. It makes the other
helpers unused, so mark them inline to prevent warnings.
Rewrite and simplify init_vectorized_lexer.
libcpp/ChangeLog:
* files.cc (read_file_g
Since the characters we are searching for (CR, LF, '\', '?') all have
distinct ASCII codes mod 16, PSHUFB can help match them all at once.
libcpp/ChangeLog:
* lex.cc (search_line_sse42): Replace with...
(search_line_ssse3): ... this new function. Adjust the use...
(init_v
Upcoming patches first drop Binutils ISA support from SSE4.2 to SSSE3,
then bump it to AVX2. Instead of fiddling with detection, just bump
our configure check to AVX2 immediately: if by some accident somebody
builds GCC without AVX2 support in the assembler, they will get SSE2
vectorized lexer, whi
Hello!
As discussed, I'm sending patches that reimplement our SSE4.2 search_line_fast
helper with SSSE3, and then add the corresponding AVX2 helper. They are on top
of Andi's "Remove MMX code path in lexer" patch, which was approved, but not
committed yet (Andi, can you push your own patch?).
App
On Tue, 30 Jul 2024, Andi Kleen wrote:
> > I have looked at this code before. When AVX2 is available, so is SSSE3,
> > and then a much more efficient approach is available: instead of comparing
> > against \r \n \\ ? one-by-one, build a vector
> >
> > 0 1 2 3 4 5 6 7 8 9a bc
Hi,
On Tue, 30 Jul 2024, Andi Kleen wrote:
> AVX2 is widely available on x86 and it allows to do the scanner line
> check with 32 bytes at a time. The code is similar to the SSE2 code
> path, just using AVX and 32 bytes at a time instead of SSE2 16 bytes.
>
> Also adjust the code to allow inlini
On Tue, Jul 30, 2024 at 03:00:49PM +0200, Richard Biener wrote:
> > What mangling fld performs depends on the contents of the FP control
> > word which is awkward.
For float/double loads (FLDS and FLDL) we know format conversion changes
SNaNs to QNaNs, but it's a widening conversion, so e.g. ro
On Tue, 30 Jul 2024, Jakub Jelinek wrote:
> On Tue, Jul 30, 2024 at 03:43:25PM +0300, Alexander Monakov wrote:
> >
> > On Tue, 30 Jul 2024, Richard Biener wrote:
> >
> > > > Oh, and please add a small comment why we don't use XFmode here.
> > >
On Tue, 30 Jul 2024, Richard Biener wrote:
> > Oh, and please add a small comment why we don't use XFmode here.
>
> Will do.
>
> /* Do not enable XFmode, there is padding in it and it suffers
>from normalization upon load like SFmode and DFmode when
>not using S
On Thu, 18 Jul 2024, Richard Biener wrote:
> > (also, in C op2 and op3 of a ternary operator always have integer promotions
> > applied, but for vector selection we should use unpromoted types)
>
> Yes. So a good testcase would use char typed variable then. It’s
> unfortunate C and C++ do no
On Thu, 18 Jul 2024, Richard Biener wrote:
> >If both b and c are scalars and the type of true?b:c has the same size
> >as the element type of a, then b and c are converted to a vector type
> >whose elements have this type and with the same number of elements as a.
> >
> > (in https:
On Thu, 18 Jul 2024, Richard Biener wrote:
> The following adds support for vector conditionals in C. The support
> was nearly there already but c_objc_common_truthvalue_conversion
> rejecting vector types. Instead of letting them pass there unchanged
> I chose to instead skip it when parsing
On Fri, 14 Jun 2024, Kong, Lingling wrote:
> APX CFCMOV[1] feature implements conditionally faulting which means that all
> memory faults are suppressed
> when the condition code evaluates to false and load or store a memory
> operand. Now we could load or store a
> memory operand may trap or
On Tue, 28 May 2024, Richard Biener wrote:
> > I am a bit confused what you mean by "cheaper". Could it be that we are not
> > on the same page regarding the machine code behind client requests?
>
> Probably "cheaper" in register usage.
But it doesn't matter considering that execution under Va
On Tue, 28 May 2024, Richard Biener wrote:
> On Wed, May 15, 2024 at 12:59 PM Alexander Monakov wrote:
> >
> >
> > Hello,
> >
> > I'd like to ask if anyone has any new thoughts on this patch.
> >
> > Let me also point out that valgrind/memcheck.
Hello!
I looked at ternlog a bit last year, so I'd like to offer some drive-by
comments. If you want to tackle them in a follow-up patch, or leave for
someone else to handle, please let me know.
On Fri, 17 May 2024, Roger Sayle wrote:
> This revised patch has been tested on x86_64-pc-linux-gnu
In PR 114480 we are hitting a case where tree-into-ssa scales
quadratically due to prune_unused_phi_nodes doing O(N log N)
work for N basic blocks, for each variable individually.
Sorting the 'defs' array is especially costly.
It is possible to assist gcc_qsort by laying out dfs_out entries
in the
build-time dependency on installed headers.
So maybe we have that as an option too.
Alexander
On Fri, 22 Dec 2023, Alexander Monakov wrote:
> From: Daniil Frolov
>
> PR 66487 is asking to provide sanitizer-like detection for C++ object
> lifetime violations that are worked around with
/valgrind-annotations-1.C: New test.
* g++.dg/valgrind-annotations-2.C: New test.
Co-authored-by: Alexander Monakov
---
Changes in v2:
* Take new clobber kinds into account.
* Do not link valgrind-interop.o into libgcc_s.so.
gcc/Makefile.in
On Tue, 12 Dec 2023, Richard Biener wrote:
> On Tue, Dec 12, 2023 at 3:38 PM Jan Hubicka wrote:
> >
> > Hi,
> > this patch disables use of FMA in matrix multiplication loop for generic
> > (for
> > x86-64-v3) and zen4. I tested this on zen4 and Xenon Gold Gold 6212U.
> >
> > For Intel this is
On Tue, 12 Dec 2023, Jakub Jelinek wrote:
> On Mon, Dec 11, 2023 at 05:00:50PM -0500, Jason Merrill wrote:
> > In discussion of PR71093 it came up that more clobber_kind options would be
> > useful within the C++ front-end.
> >
> > gcc/ChangeLog:
> >
> > * tree-core.h (enum clobber_kind):
On Sun, 10 Dec 2023, Richard Biener wrote:
> > It seems wrong to me: CLOBBER_EOL is documented to mean that the storage is
> > expiring at that point as well, which a (pseudo-)destructor does not imply;
> > it's perfectly valid to destroy an object and then create another in the
> > same storage.
On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> On Fri, Dec 08, 2023 at 06:43:19PM +0300, Alexander Monakov wrote:
> > On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> > > In your version, did the new function go just to libgcc.a or to
> > > libgcc_s.so.1?
> >
> >
On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> Does VALGRIND_MAKE_MEM_UNDEFINED macro ever change onarches once implemented
> there?
It seems Valgrind folks take binary compatibility seriously, so that sounds
unlikely.
> Wouldn't this be better done by emitting the sequence inline?
> Even if it is
/valgrind-annotations-1.C: New test.
* g++.dg/valgrind-annotations-2.C: New test.
Co-authored-by: Alexander Monakov
---
gcc/Makefile.in | 1 +
gcc/builtins.def | 3 +
gcc/common.opt|
I would like to propose Valgrind integration previously sent as RFC for trunk.
Arsen and Sam, since you commented on the RFC I wonder if you can have
a look at the proposed configure and documentation changes and let me
know if they look fine for you? For reference, gccinstall.info will say:
‘--e
Avoid using 'network sort' (a misnomer) in sort.cc, the correct term is
'sorting networks'.
gcc/ChangeLog:
* sort.cc: Use 'sorting networks' in comments.
---
gcc/sort.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/sort.cc b/gcc/sort.cc
index 9a0113fb62f.
cc-patches/20231024141124.210708-1-exactl...@ispras.ru/
Alexander Monakov (2):
libcpp: configure: drop unused Valgrind detection
gcc: configure: drop Valgrind 3.1 compatibility
gcc/config.in | 12 ---
gcc/configure | 80 +++--
gcc/configure.
When top-level configure has either --enable-checking=valgrind or
--enable-valgrind-annotations, we want to activate a couple of workarounds
in libcpp. They do not use anything from the Valgrind API, so just
delete all detection.
libcpp/ChangeLog:
* config.in: Regenerate.
* config
Our system.h and configure.ac try to accommodate valgrind-3.1, but it is
more than 15 years old at this point. As Valgrind-based checking is a
developer-oriented feature, drop the compatibility stuff and streamline
the detection.
gcc/ChangeLog:
* config.in: Regenerate.
* configure
On Tue, 21 Nov 2023, Maxim Kuvyrkov wrote:
> This patch avoids sched-deps.cc:find_inc() creating exponential number
> of dependencies, which become memory and compilation time hogs.
> Consider example (simplified from PR96388) ...
> ===
> sp=sp-4 // sp_insnA
> mem_i
On Tue, 21 Nov 2023, Richard Biener wrote:
> and this, too, btw. - the DSE actually happens, the latter transform not.
> We specifically "opt out" of doing that for QOI to not make undefined
> behavior worse. The more correct transform would be to replace the
> load with a __builtin_trap () dur
On Tue, 21 Nov 2023, Alexander Monakov wrote:
> I am concerned that if GCC ever learns to leave out the following access
> to 'this->foo', leaving tmp uninitialized, we will end up with:
>
> this->foo = 42;
Sorry, this store will be DSE'd out,
On Mon, 13 Nov 2023, Richard Biener wrote:
> > Ideally we'd position it such that more locals are put in SSA form,
> > but not too late to miss some UB, right? Perhaps after first pass_ccp?
>
> I guess it’s worth experimenting. Even doing it right before RTL expansion
> might work. Note if you
On Mon, 20 Nov 2023, Maxim Kuvyrkov wrote:
> > On Nov 20, 2023, at 17:52, Alexander Monakov wrote:
> >
> >
> > On Mon, 20 Nov 2023, Maxim Kuvyrkov wrote:
> >
> >> This patch avoids sched-deps.cc:find_inc() creating exponential number
> >> of d
On Mon, 20 Nov 2023, Maxim Kuvyrkov wrote:
> This patch avoids sched-deps.cc:find_inc() creating exponential number
> of dependencies, which become memory and compilation time hogs.
> Consider example (simplified from PR96388) ...
> ===
> sp=sp-4 // sp_insnA
> mem_insnA1[sp+A1]
> ...
> mem_insnA
On Fri, 17 Nov 2023, Kewen.Lin wrote:
> > I don't think you can run cleanup_cfg after sched_init. I would suggest
> > to put it early in schedule_insns.
>
> Thanks for the suggestion, I placed it at the beginning of haifa_sched_init
> instead, since schedule_insns invokes haifa_sched_init, altho
On Wed, 15 Nov 2023, Kewen.Lin wrote:
> >> And I suppose it would be OK to do that. Empty BBs are usually removed by
> >> CFG cleanup so the situation should only happen in rare corner cases where
> >> the fix would be to actually run CFG cleanup ...
> >
> > Yeah, sel-sched invokes 'cfg_cleanu
On Mon, 13 Nov 2023, Richard Biener wrote:
> Another generic comment - placing a built-in call probably pessimizes code
> generation unless we handle it specially during alias analysis (or in
> builtin_fnspec).
But considering the resulting code is intended to be run under Valgrind,
isn't a bit
On Sat, 11 Nov 2023, Sam James wrote:
> > Valgrind client requests are offered as macros that emit inline asm. For
> > use
> > in code generation, we need to wrap it in a built-in. We know that
> > implementing
> > such a built-in in libgcc is undesirable, [...].
>
> Perhaps less objectiona
On Sat, 11 Nov 2023, Arsen Arsenović wrote:
> > +#else
> > +# define VALGRIND_MAKE_MEM_UNDEFINED(ptr, sz) __builtin_trap ()
> > +#endif
> > +
> > +void __valgrind_make_mem_undefined (void *ptr, unsigned long sz)
> > +{
> > + VALGRIND_MAKE_MEM_UNDEFINED (ptr, sz);
> > +}
>
> Would it be preferab
On Fri, 10 Nov 2023, Richard Biener wrote:
> On Fri, Nov 10, 2023 at 3:18 PM Alexander Monakov wrote:
> >
> >
> > On Fri, 10 Nov 2023, Richard Biener wrote:
> >
> > > > I'm afraid ignoring debug-only BBs goes contrary to overall
> > > >
On Fri, 10 Nov 2023, Richard Biener wrote:
> > I'm afraid ignoring debug-only BBs goes contrary to overall var-tracking
> > design:
> > DEBUG_INSNs participate in dependency graph so that schedulers can remove or
> > mutate them as needed when moving real insns across them.
>
> Note that debug
On Thu, 9 Nov 2023, Jeff Law wrote:
> > Yeah, I noticed that the scheduler takes care of DEBUG_INSNs as normal
> > operations. When I started to work on this issue, initially I wanted to try
> > something similar to your idea #2, but when checking the APIs, I realized
> > why not just skip the
On Thu, 9 Nov 2023, Maxim Kuvyrkov wrote:
> Hi Kewen,
>
> Below are my comments. I don't want to override Alexander's review, and if
> the patch looks good to him, it's fine to ignore my concerns.
>
> My main concern is that this adds a new entity -- forceful skipping of
> DEBUG_INSN-only bas
On Wed, 8 Nov 2023, Richard Biener wrote:
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.dg/setjmp-7.c
> >> @@ -0,0 +1,13 @@
> >> +/* { dg-do compile } */
> >> +/* { dg-options "-O2 -fno-guess-branch-probability -w" } */
> >> +/* { dg-require-effective-target indirect_jumps } */
> >> +
> >> +str
On Thu, 28 Sep 2023, Siddhesh Poyarekar wrote:
> Define a security process and exclusions to security issues for GCC and
> all components it ships.
Some typos and wording suggestions below.
> --- /dev/null
> +++ b/SECURITY.txt
> @@ -0,0 +1,205 @@
> +What is a GCC security bug?
> +=
On Tue, 26 Sep 2023, Jeff Law wrote:
> What ultimately pushed us to keep moving forward on this effort was
> discovering numerous CRC loop implementations out in the wild, including 4
> implementations (IIRC) in the kernel itself.
The kernel employs bitwise CRC only in look-up table generators.
ffmpeg, zlib, bzip2, xz-utils, and zstd I'm aware of only
a single instance where bitwise CRC is used. It's in the table
initialization function in xz-utils. The compiler would transform that
to copying one table into another. Is that a valuable transform?
> Alexander Monakov:
> > U
On Fri, 15 Sep 2023, Richard Biener via Gcc-patches wrote:
> +@itemize @bullet
> +@item
> +When the result of negation, addition, subtraction or division of two signed
> +integers or signed integer vectors not subject to @option{-fwrapv} cannot be
> +represented in the type.
It would be a bit a
On Wed, 16 Aug 2023, Philipp Tomsich wrote:
> > > I fully expect that latency to drop within the next 12-18 months. In that
> > > world, there's not going to be much benefit to using hand-coded libraries
> > > vs
> > > just letting the compiler do it.
>
> I would also hope that the hand-coded
On Tue, 15 Aug 2023, Jeff Law wrote:
> Because if the compiler can optimize it automatically, then the projects have
> to do literally nothing to take advantage of it. They just compile normally
> and their bitwise CRC gets optimized down to either a table lookup or a clmul
> variant. That's t
On Wed, 16 Aug 2023, Siddhesh Poyarekar wrote:
> > Yeah, indicating scenarios that fall outside of intended guarantees should
> > be helpful. I feel the exact text quoted above will be hard to decipher
> > without knowing the discussion that led to it. Some sort of supplementary
> > section with
On Wed, 16 Aug 2023, Siddhesh Poyarekar wrote:
> No I understood the distinction you're trying to make, I just wanted to point
> out that the effect isn't all that different. The intent of the wording is
> not to prescribe a solution, but to describe what the compiler cannot do and
> hence, use
> > Unfortunately the lines that follow:
> >
> >> either sanitized by an external program to allow only trusted,
> >> safe compilation and execution in the context of the application,
> >
> > again make a reference to a purely theoretical "external program" that
> > is not going to ex
On Tue, 15 Aug 2023, David Malcolm via Gcc-patches wrote:
> I'd prefer to reword this, as libgccjit was a poor choice of name for
> the library (sorry!), to make it clearer it can be used for both ahead-
> of-time and just-in-time compilation, and that as used for compilation,
> the host conside
On Tue, 15 Aug 2023, Paul Koning wrote:
> Now I'm confused. I thought the whole point of what GCC is trying to, and
> wants to document, is that it DOES preserve security properties. If the
> source code is standards-compliant and contains algorithms free of security
> holes, then the compiler
On Tue, 15 Aug 2023, David Edelsohn wrote:
> > Making users responsible for verifying that sources are "safe" is not okay
> > (we cannot teach them how to do that since there's no general method).
> > Making users responsible for sandboxing the compiler is fine (there's
> > a range of sandboxing
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
> > Thanks, this is nicer (see notes below). My main concern is that we
> > shouldn't pretend there's some method of verifying that arbitrary source
> > code is "safe" to pass to an unsandboxed compiler, nor should we push
> > the responsibility of
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
> Does this as the first paragraph address your concerns:
Thanks, this is nicer (see notes below). My main concern is that we shouldn't
pretend there's some method of verifying that arbitrary source code is "safe"
to pass to an unsandboxed compiler
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
> There's no practical (programmatic) way to do such validation; it has to be a
> manual audit, which is why source code passed to the compiler has to be
> *trusted*.
No, I do not think that is a logical conclusion. What is the problem with
passing
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
> 1. It makes it clear to users of the project the scope in which the project
> could be used and what safety it could reasonably expect from the project. In
> the context of GCC for example, it cannot expect the compiler to do a safety
> check of
On Fri, 11 Aug 2023, Richard Biener wrote:
> > I think it converts SNan to QNan (when the partial vector has just one
> > element which is SNan), so is a test for -fsignaling-nans missing?
>
> Hm, I guess that's a corner case that could happen when there's no
> runtime profitability check on mo
On Fri, 11 Aug 2023, Richard Biener wrote:
> When we vectorize fold-left reductions with partial vectors but
> no target operation available we use a vector conditional to force
> excess elements to zero. But that doesn't correctly preserve
> the sign of zero. The following patch disables part
On Wed, 9 Aug 2023, Richard Biener via Gcc-patches wrote:
> The following teaches the non-loop reduction vectorization code to
> handle non-associatable reductions. Using the existing FOLD_LEFT_PLUS
> internal functions might be possible but I'd have to convince myself
> that +0.0 + x[0] is a s
On Tue, 8 Aug 2023, Jeff Law wrote:
> If the compiler can identify a CRC and collapse it down to a table or clmul,
> that's a major win and such code does exist in the real world. That was the
> whole point behind the Fedora experiment -- to determine if these things are
> showing up in the real
On Tue, 8 Aug 2023, Jeff Law wrote:
> That was my thinking at one time. Then we started looking at the distros and
> found enough crc implementations in there to change my mind about the overall
> utility.
The ones I'm familiar with are all table-based and look impossible to
pattern-match (and
On Thu, 3 Aug 2023, Jeff Law wrote:
> The end goal here is to actually detect bitwise CRC implementations in the
> gimple optimizers and turn them into table lookups or carryless multiplies in
> RTL.
>
> Mariam has that working end-to-end and has proposed a talk for the Cauldron on
> the topic.
On Thu, 27 Jul 2023, Liu, Hongtao via Gcc-patches wrote:
> > +;; If the first and the second operands of ternlog are invariant and ;;
> > +the third operand is memory ;; then we should add load third operand
> > +from memory to register and ;; replace first and second operands with
> > +this reg
On Fri, 21 Jul 2023, Xi Ruoyao wrote:
> > See also PR 99903 for an earlier known issue which appears due to x87
> > excess precision and so tweaking -ffp-contract wouldn't help:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99903
>
> Does it affect AArch64 too?
Well, not literally (A
On Fri, 21 Jul 2023, Xi Ruoyao via Gcc-patches wrote:
> Perhaps -ffp-contract=on (not off) is enough to fix the issue (if you
> are building GCC 14 snapshot). The default is "fast" (if no -std=
> option is used), which allows some contractions disallowed by the
> standard.
Not fully, see below
On Mon, 17 Jul 2023, Richard Biener wrote:
> > > > > OK. Btw, while I didn't spot this during review I would appreciate
> > > > > if the code could use vec.[q]sort, this should work with a lambda as
> > > > > well I think.
> > > >
> > > > That was my first use, but that hits
> > > > https://gc
On Tue, 11 Jul 2023, Michael Matz wrote:
> Hey,
>
> On Tue, 11 Jul 2023, Alexander Monakov via Gcc-patches wrote:
>
> > > > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
> > > >
> > > > This is the weak/active fo
On Tue, 11 Jul 2023, Michael Matz wrote:
> > > To that end I introduce actually two related attributes (for naming
> > > see below):
> > > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered
> >
> > This is the weak/active form; I'd suggest "preserve_high_sse".
>
> But it preser
On Tue, 11 Jul 2023, Richard Biener wrote:
> > > If a function contains calls then GCC can't know which
> > > parts of the XMM regset is clobbered by that, it may be parts
> > > which don't even exist yet (say until avx2048 comes out), so we must
> > > restrict ourself to only save/restore the S
On Mon, 10 Jul 2023, Alexander Monakov wrote:
> > I chose to make it possible to write function definitions with that
> > attribute with GCC adding the necessary callee save/restore code in
> > the xlogue itself.
>
> But you can't trivially restore if the callee i
On Mon, 10 Jul 2023, Michael Matz via Gcc-patches wrote:
> Hello,
>
> the ELF psABI for x86-64 doesn't have any callee-saved SSE
> registers (there were actual reasons for that, but those don't
> matter anymore). This starts to hurt some uses, as it means that
> as soon as you have a call (say
On Mon, 10 Jul 2023, liuhongt via Gcc-patches wrote:
> False dependency happens when destination is only updated by
> pternlog. There is no false dependency when destination is also used
> in source. So either a pxor should be inserted, or input operand
> should be set with constraint '0'.
>
>
Ping. OK for trunk?
On Mon, 5 Jun 2023, Alexander Monakov wrote:
> Ping for the front-end maintainers' input.
>
> On Mon, 22 May 2023, Richard Biener wrote:
>
> > On Thu, May 18, 2023 at 11:04 PM Alexander Monakov via Gcc-patches
> > wrote:
> > >
> &
Ping for the front-end maintainers' input.
On Mon, 22 May 2023, Richard Biener wrote:
> On Thu, May 18, 2023 at 11:04 PM Alexander Monakov via Gcc-patches
> wrote:
> >
> > Implement -ffp-contract=on for C and C++ without changing default
> > behavior (=off for -st
On Fri, 2 Jun 2023, Matthias Kretz wrote:
> > Okay, I see opinions will vary here. I was thinking about our immintrin.h
> > which is partially implemented in terms of generic vectors. Imagine we
> > extend UBSan to trap on signed overflow for vector types. I expect that
> > will blow up on exist
On Fri, 2 Jun 2023, Matthias Kretz wrote:
> On Thursday, 1 June 2023 20:25:14 CEST Alexander Monakov wrote:
> > On Wed, 31 May 2023, Richard Biener wrote:
> > > So yes, we probably should clarify the semantics to match the
> > > implementation (since we have two targe
On Wed, 31 May 2023, Richard Biener wrote:
> On Tue, May 30, 2023 at 4:49 PM Alexander Monakov wrote:
> >
> >
> > On Thu, 25 May 2023, Richard Biener wrote:
> >
> > > On Wed, May 24, 2023 at 8:36 PM Alexander Monakov
> > > wrote:
> > >
On Thu, 25 May 2023, Richard Biener wrote:
> On Wed, May 24, 2023 at 8:36 PM Alexander Monakov wrote:
> >
> >
> > On Wed, 24 May 2023, Richard Biener via Gcc-patches wrote:
> >
> > > I’d have to check the ISAs what they actually do here - it of course
>
On Wed, 24 May 2023, Richard Biener via Gcc-patches wrote:
> I’d have to check the ISAs what they actually do here - it of course depends
> on RTL semantics as well but as you say those are not strictly defined here
> either.
Plus, we can add the following executable test to the testsuite:
#in
On Wed, 24 May 2023, Richard Biener wrote:
> On Wed, May 24, 2023 at 2:54 PM Alexander Monakov via Gcc-patches
> wrote:
> >
> > Explicitly say that bitwise shifts for narrow types work similar to
> > element-wise C shifts with integer promotions, which coincides w
Explicitly say that bitwise shifts for narrow types work similar to
element-wise C shifts with integer promotions, which coincides with
OpenCL semantics.
gcc/ChangeLog:
* doc/extend.texi (Vector Extensions): Clarify bitwise shift
semantics.
---
gcc/doc/extend.texi | 7 ++-
1
On Tue, 23 May 2023, Richard Biener wrote:
> > Ah, no, I deliberately decided against that, because that way we would go
> > via gimplify_arg, which would emit all side effects in *pre_p. That seems
> > wrong if arguments had side-effects that should go in *post_p.
>
> Ah, true - that warrants a
On Mon, 22 May 2023, Richard Biener wrote:
> On Thu, May 18, 2023 at 11:04 PM Alexander Monakov via Gcc-patches
> wrote:
> >
> > Implement -ffp-contract=on for C and C++ without changing default
> > behavior (=off for -std=cNN, =fast for C++ and -std=gnuNN).
>
Implement -ffp-contract=on for C and C++ without changing default
behavior (=off for -std=cNN, =fast for C++ and -std=gnuNN).
gcc/c-family/ChangeLog:
* c-gimplify.cc (fma_supported_p): New helper.
(c_gimplify_expr) [PLUS_EXPR, MINUS_EXPR]: Implement FMA
contraction.
gcc/C
Since tree-ssa-math-opts may freely contract across statement boundaries
we should enable it only for -ffp-contract=fast instead of disabling it
for -ffp-contract=off.
No functional change, since -ffp-contract=on is not exposed yet.
gcc/ChangeLog:
* tree-ssa-math-opts.cc (convert_mult_to
1 - 100 of 1002 matches
Mail list logo
