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 it
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 SPE
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 patch
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 probably
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 i
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 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 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
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 patches
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 infrastructur
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 ni
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 pat
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 optimiz
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_NU
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 san
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 = (sanopt
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 pre
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 ju
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 bl
19 matches
Mail list logo
