Don't assume that stack slots can only be accessed by stack or frame
registers. We first find all registers defined by stack or frame
registers. Then check memory accesses by such registers, including
stack and frame registers.
gcc/
PR target/109780
* config/i386/i386.cc (ix86_u
On Mon, Jul 10, 2023 at 3:32 AM Richard Biener
wrote:
>
> On Fri, Jul 7, 2023 at 5:14 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Don't assume that stack slots can only be accessed by stack or frame
> > registers. We first find all registers defined by stack or
Don't assume that stack slots can only be accessed by stack or frame
registers. We first find all registers defined by stack or frame
registers. Then check memory accesses by such registers, including
stack and frame registers.
gcc/
PR target/109780
* config/i386/i386.cc (ix86_u
Don't assume that stack slots can only be accessed by stack or frame
registers. Also check memory accesses from registers defined by
stack or frame registers.
gcc/
PR target/109780
* config/i386/i386.cc (ix86_set_with_register_source): New.
(ix86_find_all_stack_access): L
On Wed, May 10, 2023 at 2:17 AM Uros Bizjak wrote:
>
> On Tue, May 9, 2023 at 10:58 AM Ard Biesheuvel wrote:
> >
> > The small and medium PIC code models generate profiling calls that
> > always load the address of __fentry__() via the GOT, even if
> > -mdirect-extern-access is in effect.
> >
> >
On Thu, Apr 27, 2023 at 12:03 AM Martin Liška wrote:
>
> On 4/27/23 04:32, H.J. Lu via Gcc-patches wrote:
> > cherry-pick:
>
> Can you please wait a few days before it? I'm going to merge again
> in the near future after https://reviews.llvm.org/D144073 got
cherry-pick:
05551c658269 [sanitizer] Correct alignment of x32 __sanitizer_siginfo
* sanitizer_common/sanitizer_platform_limits_posix.h
(__sanitizer_siginfo_pad): Use u64 to align x32
__sanitizer_siginfo to 8 bytes.
---
.../sanitizer_common/sanitizer_platform_limits_posix
On Wed, Apr 26, 2023 at 4:37 PM H.J. Lu wrote:
>
> On Wed, Apr 26, 2023 at 1:24 PM Martin Liška wrote:
> >
> > On 4/26/23 21:23, H.J. Lu wrote:
> > > On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote:
> > >>
> > >> On 11/15/22 16:47, Martin Liška wrote:
> > >>> Hi.
> > >>>
> > >>> I've just pus
On Wed, Apr 26, 2023 at 1:24 PM Martin Liška wrote:
>
> On 4/26/23 21:23, H.J. Lu wrote:
> > On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote:
> >>
> >> On 11/15/22 16:47, Martin Liška wrote:
> >>> Hi.
> >>>
> >>> I've just pushed libsanitizer update that was tested on x86_64-linux and
> >>> p
On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote:
>
> On 11/15/22 16:47, Martin Liška wrote:
> > Hi.
> >
> > I've just pushed libsanitizer update that was tested on x86_64-linux and
> > ppc64le-linux systems.
> > Moreover, I run bootstrap on x86_64-linux and checked ABI difference with
> > abi
On Wed, Mar 22, 2023 at 3:19 AM Richard Biener
wrote:
>
> On Wed, Mar 22, 2023 at 8:07 AM Uros Bizjak wrote:
> >
> > On Wed, Mar 22, 2023 at 3:59 AM liuhongt wrote:
> > >
> > > The target hook is only used by i386, and the current definition is
> > > same as default gen_reg_rtx. So there's no ne
On Thu, Feb 9, 2023 at 4:12 AM Jakub Jelinek wrote:
>
> Hi!
>
> get_available_features doesn't depend on cpu_model2->__cpu_{family,model}
> and just sets stuff up based on CPUID leaf 1, or some extended ones,
> so I wonder why are we calling it separately for Intel, AMD and Zhaoxin
> and not for a
cherry-pick:
742bcbf685bc compiler-rt/lib: Add .Linterceptor_sigsetjmp
PR sanitizer/108106
* hwasan/hwasan_setjmp_x86_64.S (__interceptor_setjmp): Jump
to .Linterceptor_sigsetjmp instead of __interceptor_sigsetjmp.
(__interceptor_sigsetjmp): Add a local alias,
Check invalid third argument to __builtin_ia32_prefetch when expaning
__builtin_ia32_prefetch to avoid ICE later.
gcc/
PR target/108436
* config/i386/i386-expand.cc (ix86_expand_builtin): Check
invalid third argument to __builtin_ia32_prefetch.
gcc/testsuite/
* g
-mforce-indirect-call generates invalid instruction in 32-bit MI thunk
since there are no available scratch registers in 32-bit PIC mode.
Disable -mforce-indirect-call for PIC in 32-bit mode when generating
MI thunk.
gcc/
PR target/105980
* config/i386/i386.cc (x86_output_mi_thunk
On Sun, Dec 25, 2022 at 4:58 PM Steve Kargl via Gcc-patches
wrote:
>
> On Wed, Dec 21, 2022 at 07:27:11PM -0500, Lipeng Zhu via Fortran wrote:
> > This patch try to introduce the rwlock and split the read/write to
> > unit_root tree and unit_cache with rwlock instead of the mutex to
> > increase C
On Wed, Dec 21, 2022 at 2:35 PM Jakub Jelinek wrote:
>
> On Wed, Dec 21, 2022 at 12:20:23PM -0800, H.J. Lu wrote:
> > On Mon, Dec 19, 2022 at 8:52 PM Hongtao Liu wrote:
> > >
> > > On Thu, Dec 15, 2022 at 3:45 PM Hongtao Liu wrote:
> > > >
> > > > On Thu, Dec 15, 2022 at 3:39 PM Jakub Jelinek w
On Mon, Dec 19, 2022 at 8:52 PM Hongtao Liu wrote:
>
> On Thu, Dec 15, 2022 at 3:45 PM Hongtao Liu wrote:
> >
> > On Thu, Dec 15, 2022 at 3:39 PM Jakub Jelinek wrote:
> > >
> > > On Thu, Dec 15, 2022 at 02:21:37PM +0800, liuhongt via Gcc-patches wrote:
> > > > --- a/gcc/config/i386/i386.opt
> >
Add an internal alias to __interceptor_sigsetjmp to avoid R_X86_64_PC32
relocation for "jmp __interceptor_sigsetjmp" with old assemblers.
PR sanitizer/108106
* hwasan/hwasan_setjmp_x86_64.S (__interceptor_sigsetjmp): Add
an internal alias, __interceptor_sigsetjmp_internal.
On Mon, Nov 28, 2022 at 11:04 PM Hongtao Liu wrote:
>
> On Mon, Nov 28, 2022 at 9:06 PM liuhongt wrote:
> >
> > For __builtin_ia32_vec_set_v16qi (a, -1, 2) with
> > !flag_signed_char. it's transformed to
> > __builtin_ia32_vec_set_v16qi (_4, 255, 2) in the gimple,
> > and expanded to (const_int 2
On Mon, Nov 28, 2022 at 6:40 AM Martin Liška wrote:
>
> On 11/11/22 02:26, liuhongt via Gcc-patches wrote:
> >2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced
> > several
> > target hooks(Many thanks to their work) so other backends can do similar
> > things if they have sim
On Mon, Nov 21, 2022 at 3:49 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Nov 21, 2022 at 12:22:32PM +0100, Thomas Neumann via Gcc-patches
> wrote:
> > > When dynamically linking a fast enough machine hides the latency, but when
> > > Statically linking or on slower devices this change cau
; >
> > > > On Fri, Oct 21, 2022 at 2:33 AM Richard Biener
> > > > wrote:
> > > > >
> > > > > On Thu, Oct 20, 2022 at 6:58 PM H.J. Lu via Gcc-patches
> > > > > wrote:
> > > > > >
>
Extend optimization for
_1 = __atomic_fetch_or_4 (ptr_6, 0x8000, _3);
_5 = (signed int) _1;
_4 = _5 >= 0;
to
_1 = __atomic_fetch_or_4 (ptr_6, 0x8000, _3);
_5 = (signed int) _1;
if (_5 >= 0)
gcc/
PR middle-end/102566
* tree-ssa-ccp.cc (optimize_atomic_bit_test_and): Also
When converting integer computations into vector ones, we build a chain
from an integer definition instruction together with all dependent use
instructions. The integer computations on the chain are converted to
vector ones if the total vector costs are lower than the integer ones.
Since the same
On Fri, Oct 28, 2022 at 2:34 PM Segher Boessenkool
wrote:
>
> On Wed, Oct 26, 2022 at 11:58:57AM -0700, H.J. Lu via Gcc-patches wrote:
> > In i386.md, neg patterns which set MODE_CC register like
> >
> > (set (reg:CCC FLAGS_REG)
> > (ne:CCC (match_operan
On Fri, Oct 28, 2022 at 1:35 AM Eric Botcazou wrote:
>
> > (set (reg:SI 93)
> > (neg:SI (ltu:SI (reg:CCC 17 flags) (const_int 0 [0]
> >
> > as
> >
> > (set (reg:SI 93)
> > (neg:SI (ltu:SI (const_int 1) (const_int 0 [0]
> >
> > which leads to incorrect results since LTU on MODE_CC
In i386.md, neg patterns which set MODE_CC register like
(set (reg:CCC FLAGS_REG)
(ne:CCC (match_operand:SWI48 1 "general_reg_operand") (const_int 0)))
can lead to errors when operand 1 is a constant value. If FLAGS_REG in
(set (reg:CCC FLAGS_REG)
(ne:CCC (const_int 2) (const_int 0)))
On Mon, Oct 24, 2022 at 12:12 AM Richard Biener
wrote:
>
> On Fri, Oct 21, 2022 at 6:18 PM H.J. Lu wrote:
> >
> > On Fri, Oct 21, 2022 at 2:33 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Oct 20, 2022 at 6:58 PM H.J. Lu via Gcc-pa
On Fri, Oct 21, 2022 at 2:33 AM Richard Biener
wrote:
>
> On Thu, Oct 20, 2022 at 6:58 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > commit e034c5c895722e0092d2239cd8c2991db77d6d39
> > Author: Jakub Jelinek
> > Date: Sat Dec 2 08:54:47 2017 +0100
> >
>
commit e034c5c895722e0092d2239cd8c2991db77d6d39
Author: Jakub Jelinek
Date: Sat Dec 2 08:54:47 2017 +0100
PR target/78643
PR target/80583
* expr.c (get_inner_reference): If DECL_MODE of a non-bitfield
is BLKmode for vector field with vector raw mode, use TYPE_MOD
On Fri, Oct 14, 2022 at 1:38 AM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_available_features):
> Detect PREFETCHI.
> * common/config/i386/i386-common.cc
> (OPTION_MASK_ISA2_PREFETCHI_SET,
> OPTION_MASK_IS
On Tue, Oct 18, 2022 at 4:25 PM liuhongt wrote:
>
> Fix unexpected non-canon form from gimple vector selector.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/107271
> * config/i386/i386-expand.cc (ix86_vec_perm_index_c
On Thu, Oct 13, 2022 at 8:32 AM Andrew MacLeod via Gcc-patches
wrote:
>
> Rangers on entry cache propagation already evaluates equivalences when
> calculating values. This patch also allows it to work with partial
> equivalences, and if the bit sizes are compatible, make use of those
> ranges as w
On Fri, Oct 14, 2022 at 1:32 PM Jeff Law via Gcc-patches
wrote:
>
>
> On 10/10/22 09:50, H.J. Lu via Gcc-patches wrote:
> > On Thu, Jul 28, 2022 at 5:40 AM Richard Sandiford via Gcc-patches
> > wrote:
> >> Seems this thread has become a bit heated, so I'
On Mon, Oct 10, 2022 at 5:37 PM Eugene Rozenfeld
wrote:
>
> The bug was introduced in f30e9fd33e56a5a721346ea6140722e1b193db42.
> A variable (cur_locus_e) was incorrectly declared inside a loop.
> I also moved two other declarations (last and locus) down to make
> the code more clear.
>
> Tested o
On Thu, Jul 28, 2022 at 5:40 AM Richard Sandiford via Gcc-patches
wrote:
>
> Seems this thread has become a bit heated, so I'll try to proceed
> with caution :-)
>
> In the below, I'll use "X-mode const_int" to mean "a const_int that
> is known from context to represent an X-mode value". Of cours
On Wed, Sep 21, 2022 at 1:42 PM H.J. Lu wrote:
>
> If shadow stack is enabled, when unwinding stack, we count how many stack
> frames we pop to reach the landing pad and adjust shadow stack by the same
> amount. When counting the stack frame, we compare the return address on
> normal stack agains
On Fri, Sep 30, 2022 at 4:06 PM Jeff Law wrote:
>
>
> It's a bit weird that free_dom_edge_info leaves a dangling pointer in
> e->aux. Not sure what I was thinking.
>
>
> There's two callers. One wipes e->aux immediately after the call, the
> other attaches a newly created object immediately afte
On Fri, Sep 30, 2022 at 3:25 PM Palmer Dabbelt wrote:
>
> On Sat, 24 Sep 2022 19:13:36 PDT (-0700), san...@codesourcery.com wrote:
> > On 9/18/22 02:47, Palmer Dabbelt wrote:
> >> On Fri, 09 Sep 2022 02:46:40 PDT (-0700), Palmer Dabbelt wrote:
> >>> I just happened to stuble on this one while tryi
encodekey128 and encodekey256 operations clear XMM4-XMM6. But it is
documented that XMM4-XMM6 are reserved for future usages and software
should not rely upon them being zeroed. Change encodekey128 and
encodekey256 to clobber XMM4-XMM6.
gcc/
PR target/107061
* config/i386/predic
On Tue, Sep 27, 2022 at 10:46 AM Robin Dapp via Gcc-patches
wrote:
>
> > I did bootstrapping and ran the testsuite on x86(-64), aarch64, Power9
> > and s390. Everything looks good except two additional fails on x86
> > where code actually looks worse.
> >
> > gcc.target/i386/keylocker-encodekey12
On Sat, Sep 24, 2022 at 1:37 PM Jeff Law wrote:
>
>
> On 9/21/22 16:11, H.J. Lu wrote:
> > On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >> On 9/2/2022 8:36 AM, H.J. Lu via Gcc-patches wrote:
> >>>
On Wed, Sep 7, 2022 at 10:03 AM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/2/2022 8:36 AM, H.J. Lu via Gcc-patches wrote:
> > CONCAT and CONCATN never appear in the insn chain. They are only used
> > in debug insn. Ignore debug insns with CONCAT and CONCATN for insn
If shadow stack is enabled, when unwinding stack, we count how many stack
frames we pop to reach the landing pad and adjust shadow stack by the same
amount. When counting the stack frame, we compare the return address on
normal stack against the return address on shadow stack. If they don't
match
CONCAT and CONCATN never appear in the insn chain. They are only used
in debug insn. Ignore debug insns with CONCAT and CONCATN for insn
scheduling to avoid different insn orders with and without debug insn.
gcc/
PR rtl-optimization/106746
* sched-deps.cc (sched_analyze_2): Igno
On Thu, Sep 1, 2022 at 11:23 AM Uros Bizjak via Gcc-patches
wrote:
>
> The conversion of a move pattern where both operands are AX_REG
> should be prevented.
>
> 2022-09-01 Uroš Bizjak
>
> gcc/ChangeLog:
>
> PR target/106707
> * config/i386/i386.md (moves to/from AX_REG into xchg peepho
Handle E_V16BFmode in ix86_avx256_split_vector_move_misalign and add
V16BF to V_256H iterator.
gcc/
PR target/106748
* config/i386/i386-expand.cc
(ix86_avx256_split_vector_move_misalign): Handle E_V16BFmode.
* config/i386/sse.md (V_256H): Add V16BF.
gcc/testsuite/
On Mon, Aug 22, 2022 at 7:05 PM Hongtao Liu wrote:
>
> On Tue, Aug 23, 2022 at 1:02 AM H.J. Lu wrote:
> >
> > On 64-bit Windows, long is 32 bits and can't be used as stride in memory
> > operand when base is a pointer which is 64 bits. Cast stride to
> > __PTRDIFF_TYPE__, instead of long.
> Ok.
I am checking in this as an obvious fix.
H.J.
---
Since XMM BF16 tests only require SSE2, replace vmovdqu with movdqu in
BF16 XMM ABI tests to support SSE2 machines without AVX.
Tested on x86-64 machines with and without AVX.
* gcc.target/x86_64/abi/bf16/asm-support.S: Replace vmovdqu wi
On 64-bit Windows, long is 32 bits and can't be used as stride in memory
operand when base is a pointer which is 64 bits. Cast stride to
__PTRDIFF_TYPE__, instead of long.
PR target/106714
* config/i386/amxtileintrin.h (_tile_loadd_internal): Cast to
__PTRDIFF_TYPE__.
On Thu, Aug 18, 2022 at 5:56 PM Hongtao Liu via Gcc-patches
wrote:
>
> On Thu, Aug 18, 2022 at 3:36 PM Haochen Jiang via Gcc-patches
> wrote:
> >
> > Hi all,
> >
> > This patch aims to add bf16 abi test after the whole __bf16 type is added.
> >
> > Regtested on x86_64-pc-linux-gnu. Ok for trunk?
On Wed, Aug 3, 2022 at 10:27 AM H.J. Lu wrote:
>
> On Tue, Aug 2, 2022 at 4:34 PM Jeff Law wrote:
> >
> >
> >
> > On 8/2/2022 11:43 AM, H.J. Lu wrote:
> > > On Sat, Jul 30, 2022 at 1:30 PM Jeff Law via Gcc-patches
> > > wrote:
> > >>
Check stack canary before throwing exception to avoid stack corruption.
gcc/
PR middle-end/58245
* calls.cc: Include "tree-eh.h".
(expand_call): Check stack canary before throwing exception.
gcc/testsuite/
PR middle-end/58245
* g++.dg/fstack-protector-str
On Wed, Aug 3, 2022 at 1:26 AM Richard Biener via Gcc-patches
wrote:
>
> On Wed, 3 Aug 2022, Tamar Christina wrote:
>
> >
> > > -Original Message-
> > > From: Richard Biener
> > > Sent: Tuesday, August 2, 2022 10:11 AM
> > > To: Tamar Christina
> > > Cc: Richard Biener ; ja...@redhat.com
On Tue, Aug 2, 2022 at 4:34 PM Jeff Law wrote:
>
>
>
> On 8/2/2022 11:43 AM, H.J. Lu wrote:
> > On Sat, Jul 30, 2022 at 1:30 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >> On 7/14/2022 3:55 PM, H.J. Lu via Gcc-patches wrote:
> >&
On Sat, Jul 30, 2022 at 1:30 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 7/14/2022 3:55 PM, H.J. Lu via Gcc-patches wrote:
> > Check stack canary for noreturn function to catch stack corruption
> > before calling noreturn function. For C++, check stack canary when
&
On Thu, Jul 28, 2022 at 9:31 AM H.J. Lu wrote:
>
> On Thu, Jul 28, 2022 at 1:26 AM Alexandre Oliva wrote:
> >
> > On Jul 27, 2022, "H.J. Lu" wrote:
> >
> > > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva
> > > wrote:
> >
> > >> The use of @GOTOFF for locally-bound but externally-visible sym
On Thu, Jul 28, 2022 at 9:43 AM Roger Sayle wrote:
>
>
> This patch resolves PR target/106450, some more fall-out from more
> aggressive TImode scalar-to-vector (STV) optimizations. I continue
> to be caught out by how far TImode STV has diverged from DImode/SImode
> STV, and therefore requires a
On Thu, Jul 28, 2022 at 1:26 AM Alexandre Oliva wrote:
>
> On Jul 27, 2022, "H.J. Lu" wrote:
>
> > On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva wrote:
>
> >> The use of @GOTOFF for locally-bound but externally-visible symbols
> >> (e.g. protected visibility) also breaks pointer identity if t
On Thu, Jul 21, 2022 at 11:53 AM H.J. Lu wrote:
>
> We can't always use the PLT entry as the function address for local IFUNC
> functions. When the PIC register is needed for PLT call, indirect call
> via the PLT entry will fail since the PIC register may not be set up
> properly for indirect cal
On Tue, Jul 26, 2022 at 10:14 PM Alexandre Oliva wrote:
>
>
> g++.dg/ext/attr-ifunc-3.C and gcc.target/i386/mvc10.c, not changed,
> have made it clear that there were problems in the optimizations to
> use @GOTOFF to refer to locally-bound ifuncs. GNU ld as recently as
> May 2018 would reject suc
On Fri, Jul 1, 2022 at 8:31 AM Uros Bizjak wrote:
>
> On Thu, Jun 30, 2022 at 4:50 PM H.J. Lu wrote:
> >
> > 1. Add a predicate for constant vectors which can be converted to integer
> > constants suitable for constant integer stores. For a 8-byte constant
> > vector, the converted 64-bit intege
On Fri, Jul 22, 2022 at 11:10 PM Richard Biener via Gcc-patches
wrote:
>
>
>
> > Am 22.07.2022 um 22:17 schrieb H.J. Lu via Gcc-patches
> > :
> >
> > On Thu, Jul 21, 2022 at 4:24 AM Richard Biener via Gcc-patches
> > wrote:
> >>
> >>
On Thu, Jul 21, 2022 at 4:24 AM Richard Biener via Gcc-patches
wrote:
>
> The following makes sure to fold ~(a ^ b) to a == b for truth
> values (but not vectors, we'd have to check for vector support of
> equality). That turns the PR106379 testcase into a ranger one.
>
> Note that while we arriv
We can't always use the PLT entry as the function address for local IFUNC
functions. When the PIC register is needed for PLT call, indirect call
via the PLT entry will fail since the PIC register may not be set up
properly for indirect call. Add ix86_ifunc_ref_local_ok to return false
when the PL
Check stack canary for noreturn function to catch stack corruption
before calling noreturn function. For C++, check stack canary when
throwing exception or resuming stack unwind to avoid corrupted stack.
gcc/
PR middle-end/58245
* calls.cc (expand_call): Check stack canary for no
On Wed, Jul 13, 2022 at 11:42 PM Richard Biener
wrote:
>
> On Wed, Jul 13, 2022 at 6:50 PM H.J. Lu wrote:
> >
> > When memchr is applied on a constant string of no more than the bytes of
> > a word, simplify memchr by checking each byte in the constant string.
> >
> > int f (int a)
> > {
> >r
When shadow stack is enabled, function with indirect_return attribute
may return via indirect jump. In this case, we need to disable sibcall
if caller doesn't have indirect_return attribute and indirect branch
tracking is enabled since compiler won't generate ENDBR when calling the
caller.
gcc/
On Wed, Jul 13, 2022 at 5:35 AM Richard Biener
wrote:
>
> On Tue, Jul 12, 2022 at 6:59 PM H.J. Lu wrote:
> >
> > On Fri, Jul 8, 2022 at 5:54 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Jul 7, 2022 at 6:45 PM H.J. Lu wrote:
> > > >
> > > > When memchr is applied on a constant string of no m
When memchr is applied on a constant string of no more than the bytes of
a word, simplify memchr by checking each byte in the constant string.
int f (int a)
{
return __builtin_memchr ("AE", a, 2) != 0;
}
is simplified to
int f (int a)
{
return ((char) a == 'A' || (char) a == 'E') != 0;
}
On Fri, Jul 8, 2022 at 5:54 AM Richard Biener
wrote:
>
> On Thu, Jul 7, 2022 at 6:45 PM H.J. Lu wrote:
> >
> > When memchr is applied on a constant string of no more than the bytes of
> > a word, simplify memchr by checking each byte in the constant string.
> >
> > int f (int a)
> > {
> >retu
On Sun, Jul 10, 2022 at 2:38 PM Roger Sayle wrote:
>
>
> Hi HJ,
>
> I believe this should now be handled by the post-reload (CSE) pass.
> Consider the simple test case:
>
> __int128 a, b, c;
> void foo()
> {
> a = 0;
> b = 0;
> c = 0;
> }
>
> Without any STV, i.e. -O2 -msse4 -mno-stv, GCC ge
On Sun, Jul 10, 2022 at 11:36 AM Roger Sayle wrote:
>
>
> Hi Uros,
> Yes, I agree. I think it makes sense to have a single STV pass (after
> combine and before reload). Let's hear what HJ thinks, but I'm
> happy to investigate a follow-up patch that unifies the STV passes.
> But it'll be easier
; > >
> > > > On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
> > > > wrote:
> > > > >
> > > > > When memchr is applied on a constant string of no more than the bytes
> > > > > of
> > > > > a word, inli
When memchr is applied on a constant string of no more than the bytes of
a word, simplify memchr by checking each byte in the constant string.
int f (int a)
{
return __builtin_memchr ("AE", a, 2) != 0;
}
is simplified to
int f (int a)
{
return ((char) a == 'A' || (char) a == 'E') != 0;
}
On Fri, Jul 1, 2022 at 12:51 AM Richard Biener
wrote:
>
> On Mon, Jun 20, 2022 at 5:44 PM H.J. Lu wrote:
> >
> > extern int __memcmpeq (const void *, const void *, size_t);
> >
> > was was added to GLIBC 2.35. Expand BUILT_IN_MEMCMP_EQ to __memcmpeq
> > after seeing __memcmpeq prototype
>
> Can
extern int __memcmpeq (const void *, const void *, size_t);
was was added to GLIBC 2.35. Expand BUILT_IN_MEMCMP_EQ to __memcmpeq
after seeing __memcmpeq prototype
gcc/
* builtins.cc (expand_builtin): Issue an error for
BUILT_IN___MEMCMPEQ if there is no __memcmpeq prototype. Ex
1. Add a predicate for constant vectors which can be converted to integer
constants suitable for constant integer stores. For a 8-byte constant
vector, the converted 64-bit integer must be valid for store with 64-bit
immediate, which is a 64-bit integer sign-extended from a 32-bit integer.
2. Add
On Sun, Jun 26, 2022 at 10:50 PM Hongtao Liu wrote:
>
> On Tue, Jun 21, 2022 at 3:50 AM Uros Bizjak via Gcc-patches
> wrote:
> >
> > On Mon, Jun 20, 2022 at 8:14 PM H.J. Lu wrote:
> > >
> > > On Tue, May 10, 2022 at 9:25 AM H.J. Lu wrote:
> > > >
> > > > Mark a function with SYMBOL_FLAG_FUNCTIO
On Wed, Jun 22, 2022 at 11:03 PM Richard Biener
wrote:
>
> On Wed, Jun 22, 2022 at 7:13 PM H.J. Lu wrote:
> >
> > On Wed, Jun 22, 2022 at 4:39 AM Richard Biener
> > wrote:
> > >
> > > On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
> >
On Wed, Jun 22, 2022 at 4:39 AM Richard Biener
wrote:
>
> On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > When memchr is applied on a constant string of no more than the bytes of
> > a word, inline memchr by checking each byte in the constant
When memchr is applied on a constant string of no more than the bytes of
a word, inline memchr by checking each byte in the constant string.
int f (int a)
{
return __builtin_memchr ("eE", a, 2) != 0;
}
is simplified to
int f (int a)
{
return (char) a == 'e' || (char) a == 'E';
}
gcc/
On Mon, Jun 20, 2022 at 7:51 AM Uros Bizjak wrote:
>
> On Mon, Jun 20, 2022 at 4:03 PM H.J. Lu wrote:
> >
> > On Tue, Jun 14, 2022 at 12:25 PM H.J. Lu wrote:
> > >
> > > Disallow siball when calling ifunc functions with PIC register so that
> > > PIC register can be restored.
> > >
> > > gcc/
>
On Tue, May 10, 2022 at 9:25 AM H.J. Lu wrote:
>
> Mark a function with SYMBOL_FLAG_FUNCTION_ENDBR when inserting ENDBR at
> function entry. Skip the 4-byte ENDBR when emitting a direct call/jmp
> to a local function with ENDBR at function entry.
>
> This has been tested on Linux kernel.
>
> gcc/
On Mon, Jun 20, 2022 at 10:29 AM Jakub Jelinek wrote:
>
> On Mon, Jun 20, 2022 at 09:35:36AM -0700, Noah Goldstein via Gcc-patches
> wrote:
> > This patch allows for strchr(x, c) to the replace with memchr(x, c,
> > strlen(x) + 1) if strlen(x) has already been computed earlier in the
> > tree.
>
On Mon, Jun 20, 2022 at 2:39 AM Richard Biener
wrote:
>
> On Thu, Jun 16, 2022 at 1:38 AM Fangrui Song wrote:
> >
> > On Wed, Jun 15, 2022 at 2:44 PM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > On Mon, Jun 13, 2022 at 9:01 AM Richard Biener
> >
extern int __memcmpeq (const void *, const void *, size_t);
was was added to GLIBC 2.35. Expand BUILT_IN_MEMCMP_EQ to __memcmpeq
after seeing __memcmpeq prototype
gcc/
* builtins.cc (have_memcmpeq_prototype): New.
(expand_builtin): Issue an error for BUILT_IN___MEMCMPEQ if
On Tue, Jun 14, 2022 at 12:25 PM H.J. Lu wrote:
>
> Disallow siball when calling ifunc functions with PIC register so that
> PIC register can be restored.
>
> gcc/
>
> PR target/105960
> * config/i386/i386.cc (ix86_function_ok_for_sibcall): Return
> false if PIC register is
On Mon, Jun 13, 2022 at 9:01 AM Richard Biener
wrote:
>
>
>
> > Am 13.06.2022 um 16:36 schrieb H.J. Lu :
> >
> > On Mon, Jun 13, 2022 at 3:11 AM Richard Biener
> > wrote:
> >>
> >>> On Tue, Jun 7, 2022 at 9:02 PM H.J. Lu via Gcc-patch
Disallow siball when calling ifunc functions with PIC register so that
PIC register can be restored.
gcc/
PR target/105960
* config/i386/i386.cc (ix86_function_ok_for_sibcall): Return
false if PIC register is used when calling ifunc functions.
gcc/testsuite/
PR t
On Mon, Jun 13, 2022 at 3:11 AM Richard Biener
wrote:
>
> On Tue, Jun 7, 2022 at 9:02 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > Add -fextra-libc-function=memcmpeq to map
> >
> > extern int __memcmpeq (const void *, const void *, size_t);
> >
Since F16C and VAES are only usable with AVX, require AVX for F16C and
VAES.
OK for master and release branches?
Thanks.
H.J.
---
libgcc/105920
* common/config/i386/cpuinfo.h (get_available_features): Require
AVX for F16C and VAES.
---
gcc/common/config/i386/cpuinfo.h |
On Fri, Jun 10, 2022 at 7:44 AM H.J. Lu wrote:
>
> On Fri, Jun 10, 2022 at 2:38 AM Florian Weimer wrote:
> >
> > * liuhongt via Libc-alpha:
> >
> > > +\subsubsection{Special Types}
> > > +
> > > +The \code{__Bfloat16} type uses a 8-bit exponent and 7-bit mantissa.
> > > +It is used for \code{BF16
On Fri, Jun 10, 2022 at 2:38 AM Florian Weimer wrote:
>
> * liuhongt via Libc-alpha:
>
> > +\subsubsection{Special Types}
> > +
> > +The \code{__Bfloat16} type uses a 8-bit exponent and 7-bit mantissa.
> > +It is used for \code{BF16} related intrinsics, it cannot be
Please mention that this is an
Add -fextra-libc-function=memcmpeq to map
extern int __memcmpeq (const void *, const void *, size_t);
which was added to GLIBC 2.35, to __builtin_memcmp_eq.
gcc/
* builtins.cc: Include "opts.h".
(expand_builtin): Generate BUILT_IN_MEMCMP_EQ if __memcmpeq is
available.
On Sun, Jun 5, 2022 at 7:27 PM Hongtao Liu via Gcc-patches
wrote:
>
> On Mon, Jun 6, 2022 at 3:17 AM Uros Bizjak via Gcc-patches
> wrote:
> >
> > On Thu, Jun 2, 2022 at 5:04 PM Jan Beulich wrote:
> > >
> > > The 64-bit, 128-bit, and 512-bit variants have VDI return type, in
> > > line with instr
On Fri, May 13, 2022 at 1:17 PM Philipp Tomsich
wrote:
>
> The Zbb support has introduced ctz and clz to the backend, but some
> transformations in GCC need to know what the value of c[lt]z at zero
> is. This affects how the optab is generated and may suppress use of
> CLZ/CTZ in tree passes.
>
>
On Wed, Jun 1, 2022 at 12:20 AM Richard Sandiford
wrote:
>
> "H.J. Lu" writes:
> > On Mon, May 30, 2022 at 09:35:43AM +0100, Richard Sandiford wrote:
> >> "H.J. Lu" writes:
> >> > ---
> >> > RTL DSE tracks redundant constant stores within a basic block. When RTL
> >> > loop invariant motion hoi
On Tue, May 31, 2022 at 10:06 PM Cui,Lili wrote:
>
> This patch is to update {skylake,icelake,alderlake}_cost to add a bit
> preference to vector store.
> Since the interger vector construction cost has changed, we need to adjust
> the load and store costs for intel processers.
>
> With the patc
1 - 100 of 1039 matches
Mail list logo
