If in the future we e.g. IPA-prop propagate the nonfreeing_call_p
property through the callgraph (as in, if the function you call
is non-overridable and you know the flag for it, use it),
FYI we tried this on SPEC and some other apps but saw no performance
improvements.
Yes, we have a
On Wed, Nov 12, 2014 at 12:46:48PM +0400, Maxim Ostapenko wrote:
If in the future we e.g. IPA-prop propagate the nonfreeing_call_p
property through the callgraph (as in, if the function you call
is non-overridable and you know the flag for it, use it),
FYI we tried this on SPEC and some
On 11/12/2014 02:10 PM, Jakub Jelinek wrote:
On Wed, Nov 12, 2014 at 12:46:48PM +0400, Maxim Ostapenko wrote:
If in the future we e.g. IPA-prop propagate the nonfreeing_call_p
property through the callgraph (as in, if the function you call
is non-overridable and you know the flag for it, use
On 11/03/2014 05:27 PM, Marek Polacek wrote:
Another shot at optimizing redundant UBSAN_NULL statements.
This time we walk the dominator tree - that should result in
more effective optimization - and keep a list of UBSAN_NULL
statements that dominate the current block, see the comment
before
On Wed, Nov 05, 2014 at 12:19:22PM +0300, Yury Gribov wrote:
On 11/03/2014 05:27 PM, Marek Polacek wrote:
Another shot at optimizing redundant UBSAN_NULL statements.
This time we walk the dominator tree - that should result in
more effective optimization - and keep a list of UBSAN_NULL
On 11/05/2014 12:33 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 12:19:22PM +0300, Yury Gribov wrote:
On 11/03/2014 05:27 PM, Marek Polacek wrote:
Another shot at optimizing redundant UBSAN_NULL statements.
This time we walk the dominator tree - that should result in
more effective
On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
Are you going to work on ASan soon? I could rebase my patches on top of
Marek's infrastructure.
I'm not going to work on ASan today or tomorrow, but it'd be nice to
get this ASan opt in in this stage1.
So if you can rebase your
On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
Are you going to work on ASan soon? I could rebase my patches on top of
Marek's infrastructure.
I'm not going to work on ASan today or tomorrow, but it'd be nice to
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
Are you going to work on ASan soon? I could rebase my patches on top of
Marek's infrastructure.
On 11/05/2014 02:23 PM, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
Are you going to work on ASan soon? I could rebase my
On Wed, Nov 05, 2014 at 03:16:49PM +0300, Yury Gribov wrote:
On 11/05/2014 02:23 PM, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 12:54:37PM +0300, Yury Gribov wrote:
On 11/05/2014 03:21 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 03:16:49PM +0300, Yury Gribov wrote:
On 11/05/2014 02:23 PM, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM +0100, Marek Polacek wrote:
On Wed, Nov 05,
On 11/05/2014 03:34 PM, Yury Gribov wrote:
On 11/05/2014 03:21 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 03:16:49PM +0300, Yury Gribov wrote:
On 11/05/2014 02:23 PM, Marek Polacek wrote:
On Wed, Nov 05, 2014 at 11:50:20AM +0100, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 11:29:19AM
On Wed, Nov 05, 2014 at 04:13:01PM +0300, Yury Gribov wrote:
Wouldn't it break most uses of __asan_poison_memory_region ?
Most probably but I wonder if we should ask people to simply do asm
volatile with memory clobber in this case? And we probably shouldn't
call the whole thing
On 11/05/2014 04:23 PM, Jakub Jelinek wrote:
On Wed, Nov 05, 2014 at 04:13:01PM +0300, Yury Gribov wrote:
Wouldn't it break most uses of __asan_poison_memory_region ?
Most probably but I wonder if we should ask people to simply do asm
volatile with memory clobber in this case? And we
On Mon, Nov 03, 2014 at 04:35:00PM +0100, Jakub Jelinek wrote:
Well, in theory you could just script removing them one by one and just
make sanopt.o after each step to see if the header is or is not needed,
perhaps with some manual tweeks.
I pruned those headers some more.
Perhaps in
On Tue, Nov 04, 2014 at 07:36:26PM +0100, Marek Polacek wrote:
+ FOR_EACH_VEC_ELT_REVERSE (v, i, g)
+ {
+ /* Remove statements for BBs that have been
+ already processed. */
+ sanopt_info *si =
Another shot at optimizing redundant UBSAN_NULL statements.
This time we walk the dominator tree - that should result in
more effective optimization - and keep a list of UBSAN_NULL
statements that dominate the current block, see the comment
before sanopt_optimize_walker. Statements coming from
On Mon, Nov 03, 2014 at 03:27:57PM +0100, Marek Polacek wrote:
I moved all of this into new sanopt.c file.
(I guess that file includes some headers that we in fact don't
need, but the header flattening doesn't make it easy to check,
there are too many of them.)
Well, in theory you could just
19 matches
Mail list logo
