On 11/26/21 23:34, Jakub Jelinek wrote:
On Fri, Nov 26, 2021 at 11:29:41PM +0530, Siddhesh Poyarekar wrote:
The trees in object_sizes are each a TREE_VEC with the first element
being the bytes from the pointer to the end of the object and the
second, the size of the whole object. This allows
authored-by: Martin Liška
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/pr103456.c | 21 +
gcc/tree-object-size.c | 3 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/pr103456.c
diff --git a/gcc/testsuite/gcc.dg
456
* tree-object-size.c (merge_object_sizes): Update osi->changed
only if object_sizes_set succeeded.
gcc/testsuite/ChangeLog:
PR tree-optimization/103456
* gcc.dg/ubsan/pr103456.c: New test.
Co-authored-by: Martin Liška
Signed-off-by: Siddhesh Poyarekar
---
gcc/tes
/builtin-dynamic-object-size-0.c (test_parmsz_simple):
New function.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 11
gcc/tree-object-size.c| 50 ++-
2 files changed, 60 insertions
ges to individual patches have been mentioned in the patches
themselves.
- Dropped patch to remove check_for_plus_in_for_loops and osi->pass
- Merge negative offset support (10/10 in v2) into 3/8 and support
static object sizes
- Merge dynamic offset (10/10 in v2) support into 8/8
Siddhesh Poyare
-dynamic-object-size-9.c: Likewise.
* gcc.dg/builtin-object-size-16.c: Adjust to allow inclusion
from builtin-dynamic-object-size-16.c.
* gcc.dg/builtin-object-size-17.c: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
gcc/builtins.c| 11 +-
gcc
/builtin-object-size-4.c [__builtin_object_size]:
Likewise.
* gcc.dg/builtin-object-size-5.c [__builtin_object_size]:
Likewise.
Signed-off-by: Siddhesh Poyarekar
---
gcc/builtins.c| 6 +-
.../gcc.dg/builtin-dynamic-object-size-0.c| 72
)
[__builtin_object_size]: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 158 ++
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 30 +++-
gcc/testsuite/gcc.dg/builtin-object-size-2.c | 43 -
gcc/testsuite/gcc.dg/builtin-object
)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-3.c (test1)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-4.c (test1)
[__builtin_object_size]: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object
): New test.
(main): Call it.
* gcc.dg/builtin-object-size-4.c (test8): New test.
(main): Call it.
* gcc.dg/builtin-object-size-5.c (test5, test6, test7): New
tests.
Signed-off-by: Siddhesh Poyarekar
---
gcc/builtins.c | 10 +-
gcc
On 12/15/21 20:51, Jakub Jelinek wrote:
Shouldn't this also tree_int_cst_compare (old_wholeval, wholeval) ?
AFAICT, there is no situation where wholeval changes but val doesn't, so
I believe the val check should be sufficient. Do you think otherwise?
Siddhesh
On 12/15/21 21:54, Jakub Jelinek wrote:
On Wed, Dec 01, 2021 at 07:57:54PM +0530, Siddhesh Poyarekar wrote:
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
@@ -0,0 +1,72 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+typedef __SIZE_TYPE__ size_t;
+#de
On 12/16/21 00:13, Jakub Jelinek wrote:
On Wed, Dec 15, 2021 at 10:42:29PM +0530, Siddhesh Poyarekar wrote:
On 12/15/21 20:51, Jakub Jelinek wrote:
Shouldn't this also tree_int_cst_compare (old_wholeval, wholeval) ?
AFAICT, there is no situation where wholeval changes but val doesn&#x
On 12/15/21 20:54, Jakub Jelinek wrote:
On Wed, Dec 01, 2021 at 07:57:53PM +0530, Siddhesh Poyarekar wrote:
Recognize the __builtin_dynamic_object_size builtin and add paths in the
object size path to deal with it, but treat it like
__builtin_object_size for now. Also add tests to provide the
On 12/16/21 21:19, Jakub Jelinek wrote:
Yes, but please fix up formatting, wholeval should go below old_wholeval.
Though, perhaps it would be better to:
if (tree_int_cst_compare (oldval, val))
return true;
gcc_checking_assert (tree_int_cst_compare (old_wholeval, wholeval) == 0);
r
On 12/18/21 00:59, David Edelsohn wrote:
Siddhesh,
This patch series seems to have caused testsuite regressions for
memcpy-chk, etc. in 32 bit mode (i386, x86-64 -m32 and -mx32, AIX 32
bit).
I have opened PR 103759.
Thanks, I've assigned it to myself. I'll take a look.
Siddhesh
:
PR tree-optimization/103759
* tree-object-size (size_unknown_p): Construct a size_unknown
and compare with VAL.
Signed-off-by: Siddhesh Poyarekar
---
This fixes all the 32-bit torture failures on i686, tested with
configuration:
--enable-clocale=gnu --with-system-zlib
:
PR tree-optimization/103759
* tree-object-size (unknown, initval): Change to arrays. Adjust
all uses.
(init_limits): Rename from init_offset_limit. Initialize
UNKNOWN and INITVAL. Adjust all uses.
Signed-off-by: Siddhesh Poyarekar
---
Changes from v1
tree-optimization/103759
* tree-object-size (unknown, initval): Remove functions.
(size_unknown, size_initval, size_unknown_p): Operate directly
on trees.
Signed-off-by: Siddhesh Poyarekar
---
Tested a full bootstrap on x86_64, config=ubsan-bootstrap and i686.
Changes from
this new one. Also compare with
__builtin_dynamic_object_size.
- Expand the list of packages to get more coverage metrics.
- Explore performance impact on applications on building with
_FORTIFY_SOURCE=3.
Siddhesh Poyarekar (4):
tree-object-size: Support dynamic sizes in conditions
tree-o
/builtin-dynamic-object-size-0.c (test_parmsz_simple):
New function.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 11
gcc/tree-object-size.c| 50 ++-
2 files changed, 60 insertions
[__builtin_object_size]:
Likewise.
* gcc.dg/builtin-object-size-4.c [__builtin_object_size]:
Likewise.
* gcc.dg/builtin-object-size-5.c [__builtin_object_size]:
Likewise.
Signed-off-by: Siddhesh Poyarekar
---
Changes since v4:
- Propagate sameness of size
)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-3.c (test1)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-4.c (test1)
[__builtin_object_size]: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
Changes since v4:
- Free allocations
)
[__builtin_object_size]: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 158 ++
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 30 +++-
gcc/testsuite/gcc.dg/builtin-object-size-2.c | 43 -
gcc/testsuite/gcc.dg/builtin-object
r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of
which this comment about X30 not being marked as call-clobbered is no
longer accurate.
Siddhesh
* config/aarch64/aarch64.h: Remove obsolete comment.
---
gcc/config/aarch64/aarch64.h | 9 -
1 file changed, 9 dele
On 06/19/2018 09:11 PM, James Greenhalgh wrote:
On Mon, Jun 18, 2018 at 08:43:04AM -0500, Siddhesh Poyarekar wrote:
r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of
which this comment about X30 not being marked as call-clobbered is no
longer accurate.
Is the second
18-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-collision-avoidance.c: New file.
* config.gcc (extra_objs): Build it.
* config/aarch64/t-aarch64 (falkor-tag-collision-avoidance.o):
Likewise.
* config/aarch64/aa
On 07/02/2018 03:29 PM, Kyrill Tkachov wrote:
Nice! What were the regressions though? Would be nice to adjust the tests
to make them more robust so that we have as clean a testsuite as possible.
Sure, they're gcc.dg/guality/pr36728-2.c and gcc.target/aarch64/extend.c.
The addressing mode costs
yrill
- Avoid renaming R0/V0 since they could be return values
- Fixed minor formatting issues.
2018-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-collision-avoidance.c: New file.
* config.gcc (extra_objs): Build it.
* config/aa
On 07/13/2018 06:32 PM, Kyrill Tkachov wrote:
This looks good to me modulo a couple of minor comments inline.
You'll still need an approval from a maintainer.
Thanks, I'll send a fixed up version on Monday.
+ for (ause= DF_REG_USE_CHAIN (regno); ause; ause = DF_REF_NEXT_REG
(ause))
+ {
that falkor does not support sve
Changes from v1:
- Fixed up issues pointed out by Kyrill
- Avoid renaming R0/V0 since they could be return values
- Fixed minor formatting issues.
2018-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-coll
On 07/16/2018 09:59 PM, Kyrill Tkachov wrote:
I think this looks ok now. You'll still need a maintainer to approve it
though.
Thank you for the review Kyrill, but also apologies for wasting your
time on it. I just found that the patch breaks a test so I'm currently
reviewing it to see what's
From: Siddhesh Poyarekar
Hi,
Jim Wilson posted a patch for this in September[1] and it appears
following discussions that the patch was an acceptable fix for falkor.
Kugan followed up[2] with a test case since that was requested during
initial review. Jim has moved on from Linaro, so I&#
On Wednesday 17 January 2018 07:07 PM, Wilco Dijkstra wrote:
> (finished version this time, somehow Outlook loves to send emails early...)
>
> Hi,
>
> In general I think the best way to achieve this would be to use the
> existing cost models which are there for exactly this purpose. If
> this doe
On Wednesday 17 January 2018 08:31 PM, Wilco Dijkstra wrote:
> Why is that a bad thing? With the patch as is, the testcase generates:
>
> .L4:
> ldr q0, [x2, x3]
> add x5, x1, x3
> add x3, x3, 16
> cmp x3, x4
> str q0, [x5]
> bne .L4
>
>
On Wednesday 17 January 2018 11:13 PM, Wilco Dijkstra wrote:
> Are you saying the same issue exists for all stores with writeback? If so then
> your patch would need to address that too.
Yes, I'll be posting a separate patch for that because the condition set
is slightly different for it. It will
gan Vivenakandarajah
Siddhesh Poyarekar
gcc/
* gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type):
New member ADDR_QUERY_STR.
* gcc/config/aarch64/aarch64-tuning-flags.def
(SLOW_REGOFFSET_QUADWORD_STORE): New.
* gcc/config/aarch64/aarch6
Kugan Vivenakandarajah
Siddhesh Poyarekar
gcc/
* gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type):
New member ADDR_QUERY_STR.
* gcc/config/aarch64/aarch64-tuning-flags.def
(SLOW_REGOFFSET_QUADWORD_STORE): New.
* gcc/config/aarch64
From: Siddhesh Poyarekar
* MAINTAINERS (write after approval): Add myself.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@256836
138bc75d-0d04-0410-961f-82ee72b054a4
---
ChangeLog | 4
MAINTAINERS | 1 +
2 files changed, 5 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index
eed by 0.22% in CPU2017,
with omnetpp_s (4.3%) and pop2_s (2.6%) being the biggest winners.
2018-xx-xx Jim Wilson
Kugan Vivenakandarajah
Siddhesh Poyarekar
gcc/
* gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type):
New member
On Wednesday 24 January 2018 05:50 PM, Kyrill Tkachov wrote:
> I would tend towards making the costs usage more intelligent and
> differentiating
> between loads and stores but I agree that is definitely GCC 9 material.
> Whether this approach is an acceptable stopgap for GCC 8 is up to the
> aarch
On Wednesday 24 January 2018 06:29 PM, Siddhesh Poyarekar wrote:
>>> + /* Avoid register indexing for 128-bit stores when the
>>> + AARCH64_EXTRA_TUNE_SLOW_REGOFFSET_QUADWORD_STORE option is set. */
>>> + if (!optimize_size
>>&
oves fpspeed by 0.17% and intspeed by 0.62% in CPU2017,
with xalancbmk_s (3.84%) wrf_s (1.46%) and mcf_s (1.62%) being the
biggest winners. There were no regressions beyond 0.4%.
2018-xx-xx Jim Wilson
Kugan Vivenakandarajah
Siddhesh Poyarekar
gcc/
* co
Ping!
On Friday 09 February 2018 01:02 PM, Siddhesh Poyarekar wrote:
> Hi,
>
> Here's v3 of the patch to disable register offset addressing mode for
> stores of 128-bit values on Falkor because they're very costly.
> Following Kyrill's suggestion, I compared the co
On Thursday 15 February 2018 07:50 PM, Wilco Dijkstra wrote:
> So it seems to me using existing cost mechanisms is always preferable, even
> if you
> currently can't differentiate between loads and stores.
Luis is working on address cost adjustments among other things, so I
guess the path of leas
The C++ frontend generates a break that results in the fallthrough
warning misfiring in nested switch blocks where cases in the inner
switch block return, rendering the break pointless. The fallthrough
detection in finish_break_stmt does not work either because the
condition is encoded as an IF_ST
On Monday 19 February 2018 09:59 PM, Siddhesh Poyarekar wrote:
> The C++ frontend generates a break that results in the fallthrough
> warning misfiring in nested switch blocks where cases in the inner
> switch block return, rendering the break pointless. The fallthrough
>
On Tuesday 20 February 2018 03:14 PM, Jakub Jelinek wrote:
> On Mon, Feb 19, 2018 at 09:59:00PM +0530, Siddhesh Poyarekar wrote:
>> The C++ frontend generates a break that results in the fallthrough
>> warning misfiring in nested switch blocks where cases in the inner
>>
On Friday 02 February 2018 05:15 AM, Martin Sebor wrote:
> PR middle-end/84095 - false-positive -Wrestrict warnings for memcpy within
> array
>
> gcc/ChangeLog:
>
> PR middle-end/84095
> * gimple-ssa-warn-restrict.c (builtin_memref::extend_offset_range): New.
> (builtin_memref:
Libraries like gtk/glib[1] and python[2] use functions with common
argument subsets to register callbacks. The working idea behind it is
to have a flag in the structure (or some other pre-determined method)
that specifies how the callback is cast and called.
Fix this by not throwing a warning whe
On Friday 23 February 2018 09:20 PM, David Malcolm wrote:
> Do we have a PR open for this yet?
>
> I believe this is an example of where this bit (for the Python case):
> https://github.com/imageworks/OpenColorIO/pull/518
There is now:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531
Siddhe
On Friday 23 February 2018 09:22 PM, Martin Sebor wrote:
> I see no failures in this test in any of the recently reported
> results on any targets except those below:
>
> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01530.html
> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01514.html
On Saturday 24 February 2018 12:01 AM, Richard Biener wrote:
> I don't see how the function cast is valid.
>
> I've argued for void (*) () to/from void (*) (int), etc. In the past and that
> was shot down similarly. This looks like exactly the same thing.
That should not throw a warning becaus
On Saturday 24 February 2018 01:32 AM, Martin Sebor wrote:
> Casting the address of a function that takes one or more arguments
> to one that takes fewer is unsafe because when the pointer is used
> to call the function the extra arguments have indeterminate values.
> (This is also why void(*)(void
On Saturday 24 February 2018 03:28 AM, Martin Sebor wrote:
> In my mind that would be a perfectly reasonable approach.
> A variation on it might be to leave a new warning disabled
> in the first release, then include it in -Wextra the next
> release, and finally put it in -Wall.
>
> Unfortunately,
Avoid issuing a bogus warning when the source of strncpy is bound by a
constant and is known to be less than the size of the destination.
Testsuite run is underway (not complete yet, but no new errors so far)
and a bootstrap is also underway, I'll report status once they're both
done.
gcc/
On Monday 12 March 2018 03:26 PM, Richard Biener wrote:
> Please use tree_int_cst_lt (rhs1, dstsize) instead.
>
>> + {
>> + gimple_set_no_warning (stmt, true);
>
> Why this? There's only a single bit -- where do we warn from if you
> don't do this here?
I incorrectly thoug
Avoid issuing a bogus warning when the source of strncpy is bound by a
constant known to be less than the minimum size of the destination.
Changes from v1:
- Use range-info instead of the MIN_EXPR hack
- Get the minimum size of dst and check for NULL_TREE return
The patch bootstraps successfully
On Wednesday 14 March 2018 08:40 PM, Richard Biener wrote:
> Instead of building a tree from max you should use
>
> if (wi::to_widest (max) < wi::to_widest (wi::to_wide (dstsize)))
> return;
>
> given compute_objsize is somewhat confused about the type it returns
> a widest_int compare
On Friday 24 November 2017 05:36 PM, Siddhesh Poyarekar wrote:
> freq_max < 1, i.e. highest frequency among bbs in the function being
> higher than real_bb_freq_max means that the bb ends up with a profile
> count larger than real_bb_freq_max and then can go all the way up to
freq_max < 1, i.e. highest frequency among bbs in the function being
higher than real_bb_freq_max means that the bb ends up with a profile
count larger than real_bb_freq_max and then can go all the way up to
and beyond profile_count::max_count.
Bootstrapped on aarch64, testsuite in progress.
On Wednesday 29 August 2018 10:05 PM, James Greenhalgh wrote:
Sorry that this took me so long to get to. > > The code is outstanding quality, a textbook example of writing an
> analysis/optimization pass using modern GCC frameworks and data >
structures! If you ever find the opportunity, I bet
On Thursday 30 August 2018 01:28 PM, Siddhesh Poyarekar wrote:
On Wednesday 29 August 2018 10:05 PM, James Greenhalgh wrote:
Sorry that this took me so long to get to. > > The code is
outstanding quality, a textbook example of writing an
> analysis/optimization pass using m
Hi,
Here's an updated version of the patch which warns the user if the
removing of redundant exits results in an infinite loop. I have added
an additional flag in struct loop called external_exits to record if
an exit edge is moved outside the loop body. This currently happens in
the loop-unswit
Hi,
Current HEAD fails build when --enable-languages=c, i.e. C++ is not
being built. Attached patch fixes this.
Regards,
Siddhesh
ChangeLog:
2012-11-15 Siddhesh Poyarekar
* configure.ac: Disable libsanitizer if we're not building C++.
* configure: Regenerate.
diff --
Hi,
Ping!
Siddhesh
On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote:
> Hi,
>
> Here's an updated version of the patch which warns the user if the
> removing of redundant exits results in an infinite loop. I have added
> an additional flag in struct loop called external_exits to record if
>
Hi,
Ping!
Siddhesh
On Thu, 15 Nov 2012 19:52:21 +0530, Siddhesh wrote:
> Hi,
>
> Current HEAD fails build when --enable-languages=c, i.e. C++ is not
> being built. Attached patch fixes this.
>
> Regards,
> Siddhesh
>
> ChangeLog:
>
&g
Ping!
Siddhesh
On Wed, Nov 21, 2012 at 12:42:13PM +0530, Siddhesh Poyarekar wrote:
> Hi,
>
> Ping!
>
>
> Siddhesh
>
> On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote:
>
> > Hi,
> >
> > Here's an updated version of the patch which war
Ping!
Siddhesh
On Wed, Nov 21, 2012 at 12:43:10PM +0530, Siddhesh Poyarekar wrote:
> Hi,
>
> Ping!
>
> Siddhesh
>
> On Thu, 15 Nov 2012 19:52:21 +0530, Siddhesh wrote:
>
> > Hi,
> >
> > Current HEAD fails build when --enable-languages=c, i.e. C
On Tue, Nov 27, 2012 at 11:05:47AM +0100, Jakub Jelinek wrote:
> On Thu, Nov 15, 2012 at 07:52:21PM +0530, Siddhesh Poyarekar wrote:
> > 2012-11-15 Siddhesh Poyarekar
> >
> > * configure.ac: Disable libsanitizer if we're not building C++.
> > * config
Ping!
On Tue, Nov 27, 2012 at 03:32:46PM +0530, Siddhesh Poyarekar wrote:
> Ping!
>
> Siddhesh
>
> On Wed, Nov 21, 2012 at 12:42:13PM +0530, Siddhesh Poyarekar wrote:
> > Hi,
> >
> > Ping!
> >
> >
> > Siddhesh
> >
> > On
Hi,
Resending. I did not get any responses the last two times and I too
forgot about it. Can someone please review this?
Thanks,
Siddhesh
Begin forwarded message:
Date: Tue, 3 Apr 2012 18:46:53 +0530
From: Siddhesh Poyarekar
To: gcc-patches@gcc.gnu.org
Subject: Fw: [PATCH] Allow printing of
On Fri, 20 Jul 2012 22:24:57 -0400 (EDT), Hans-Peter wrote:
> Sounds like a good idea, but I think you shouldn't limit that to
> "{}" but rather introduce \ to escape and cause any next
> character to be emitted as-is, in particular "|".
I had dropped the change to escape "|" thinking it wasn't ne
this patch that
verifies that the double '|' bug I mentioned above is fixed.
Regards,
Siddhesh
[1] http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00840.html
gcc/ChangeLog:
2012-07-25 Siddhesh Poyarekar
* final.c [ASSEMBLER_DIALECT](do_assembler_dialects): New
functi
On Wed, 25 Jul 2012 08:31:14 -0700, Richard wrote:
> >
> > * gcc.dg/asm-dialect-1.c: New test case.
>
> ... except this should go in gcc.target/i386/ without the { target }
> qualifier.
>
Thanks, here's the updated version.
Regards,
Siddhesh
gcc/ChangeLog:
2
Hi,
When the location for throw() exception specification is not the same
as the function it is written against, it leads gcov to give incorrect
results. See bug 50055 for details of the the same. The following
patch makes sure that the exception specification block (nothrow or
otherwise) is alway
s...@gnu.org for more information.
>
> I think Siddhesh should be covered by the Red Hat assignment (it would help
> if the patch has been mailed from a redhat.com address to notice that).
>
Thanks! I will keep that in mind for future submissions.
--
Siddhesh Poyarekar
http://siddhesh.in
in asm string literals
without operands since they do not undergo any transformation.
The patch does not introduce any regressions. I have tested this with
x86_64 and i686 and it works well with both of them.
Regards,
Siddhesh
gcc/ChangeLog:
2012-03-27 Siddhesh Poyarekar
* final.c
Hi,
ping?
--
Siddhesh
Begin forwarded message:
Date: Tue, 27 Mar 2012 10:51:37 +0530
From: Siddhesh Poyarekar
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Allow printing of escaped curly braces in assembler
directives with operands
Hi,
An assembler directive with an operand is filtered
On 29 May 2018 at 21:17, James Greenhalgh wrote:
> On Tue, May 29, 2018 at 05:01:42AM -0500, Sameera Deshpande wrote:
>> Hi!
>>
>> Please find attached the patch to add support of ARMv8.4 in saphira
>> for Qualcomm server part. Tested on aarch64, without any regressions.
>>
>> Ok for trunk?
>
> I'
On 06/05/2018 10:02 PM, Kyrill Tkachov wrote:
Adding some folks who know more about other CPUs as well.
Are you okay with enabling these instructions in AArch64?
If you could give this a spin on some benchmarks you
care about on your platforms it would be really useful data.
Sameera had writte
301 - 381 of 381 matches
Mail list logo
