similar to: Mapping InlineAsm parameters to ConstraintInfoVector elements

Could you provide an example where MSan checks an output parameter? On Fri, Mar 16, 2018 at 9:53 AM, Alexander Potapenko via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all, > > I'm trying to figure out which parameters of a given InlineAsm instruction > are its inputs, and which are the outputs (rationale: make sure MSan > doesn't check the output parameters of

On Thu, Aug 1, 2019 at 6:09 PM JF Bastien <jfbastien at apple.com> wrote: > > Hi Alexander, > > The code doesn’t compile. Could you send a godbolt.org link that shows the issue? Sorry about that, here's the link: https://godbolt.org/z/-PinQP Lines 4 to 8 are initializing |acpar|. If I'm understanding correctly, the store to 8(%rsp) at line 7 can be removed because of the

On Thu, Aug 1, 2019 at 6:38 PM JF Bastien <jfbastien at apple.com> wrote: > > > > > On Aug 1, 2019, at 9:20 AM, Alexander Potapenko <glider at google.com> wrote: > > > > On Thu, Aug 1, 2019 at 6:09 PM JF Bastien <jfbastien at apple.com> wrote: > >> > >> Hi Alexander, > >> > >> The code doesn’t compile. Could you send

There are two problems: 1. padding after union and call to q(), without LTO we can't remove that store. 2. shortcut which I have which ignores all instructions q() . this assume that memset to acpar.match, acpar.matchinfo also useful which is not true. I should be able to improve this case. On Thu, Aug 1, 2019 at 11:29 PM Vitaly Buka <vitalybuka at google.com> wrote: > On a first

On Tue, Sep 18, 2018 at 1:56 AM Adrian Prantl <aprantl at apple.com> wrote: > > > > > On Sep 17, 2018, at 6:59 AM, Alexander Potapenko via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > (I think I've asked a similar question off-list a couple of times, but > > never got an answer) > > > > Hi folks, > > > > For [K]MSAN

(I think I've asked a similar question off-list a couple of times, but never got an answer) Hi folks, For [K]MSAN we need to figure out which inlined function a local var originally belonged to in the source file. E.g. when a local buffer %buf is declared in @bar(), but @bar() is inlined into @foo(), then there's a local %buf.i in @foo(), but we need to determine that the local came from

Hi folks, When compiling the attached example with -ftrivial-auto-var-init=zero: $ clang -no-integrated-as -mno-sse -m64 -mstack-alignment=8 -O2 -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -g -o ipt.ll -c ipt.i -w -S -emit-llvm , Clang generates an initialization memset() call for |acpar| in the IR: %0 = bitcast

Hi Alex Thanks for your email. But it seems not work. I removed the -fsanitize=address flag. The global buffer overflow message doesn't show. However, no *.sancov file is created after I run perlbench. Thus, I could not get the BB coverage. Do you have any ideas? Many Thanks Regards Muhui Alexander Potapenko <glider at google.com> 于2018年9月5日周三 下午7:14写道： > Hi Muhui, > > If

On Wed, Sep 19, 2018 at 5:18 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > > On Sep 19, 2018, at 4:08 AM, Alexander Potapenko <glider at google.com> wrote: > > > > On Tue, Sep 18, 2018 at 1:56 AM Adrian Prantl <aprantl at apple.com> wrote: > >> > >> > >> > >>> On Sep 17, 2018, at 6:59 AM, Alexander

Hi If so, is it able to disable this check. All I need is just to get the BB coverage information Regards Muhui Alexander Potapenko <glider at google.com>于2018年9月5日 周三下午6:57写道： > This is a known problem in SPECCPU2006, see > https://github.com/google/sanitizers/wiki/AddressSanitizerFoundBugs > On Wed, Sep 5, 2018 at 7:36 AM Muhui Jiang via llvm-dev > <llvm-dev at

On Mon, Apr 15, 2019 at 11:02 PM Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Apr 15, 2019, at 1:51 PM, Vitaly Buka via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hi JF, > > > > I've heard that you are interested DSE improvements and maybe we need to be in sync. > > So far I experimented with

Can you post numbers for how many stores get eliminated from CTMark? > On Apr 16, 2019, at 11:45 AM, Vitaly Buka <vitalybuka at google.com> wrote: > > I tried -Os and effect of new approach significantly increases. > I run regular DSE and immediately myDSE. With -Os myDSE removes more than 50% of DSE number. > Which is expected as -Os inlines less and regular DSE can't

> On May 10, 2019, at 8:59 PM, Vitaly Buka via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sorry for delay, I was busy with other stuff. > CTMark results. > > dse is the current DSE. > dsem is my experimental module level DSE. > dsem runs after dse, so it's additionally deleted stores. > > -O3 > dse - Number of stores deleted

Hi I am using SanitizerCoverage feature supported by clang to get the basicblock coverage. my tested binaries are spec cpu2006. I compiled the binary with the option COPTIMIZE = -O0 -fsanitize=address -fsanitize-coverage=bb -flto -fno-strict-aliasing -std=gnu89 -gdwarf-3 After the compiling process is end. I run the 400.perlbench. with the command ASAN_OPTIONS=coverage=1 ./perlbench.

Hi JF, I've heard that you are interested DSE improvements and maybe we need to be in sync. So far I experimented with following DSE improvements: * Cross-block DSE, it eliminates additional 7% stores comparing to existing DSE. But it's not visible on benchmarks. * Cross-block + Interprocedural analysis to annotate each function argument with: - can read before write - will

Hi Seeing as we (Raspberry Pi) have just launched the Compute Module 4 with an exposed PCIe x1 lane, people are asking about adding graphics cards. Seeing as you are the people who have the knowledge with regard to NVidia and nouveau, what are your immediate thoughts of nouveau working on ARM/ARM64? Is there a chance of this working? I'm no PCIe expert, although I can call on some expertise

On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote: > On 25.02.2020 12:21, Ville Syrj?l? wrote: > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > >> On 19.02.2020 21:35, Ville Syrjala wrote: > >>> From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > >>> > >>> Get rid of mode->vrefresh and just

On Sun, Jul 28, 2024 at 11:34:14PM +0200, Danilo Krummrich wrote: > On Sun, Jul 28, 2024 at 03:13:08PM -0300, Jason Gunthorpe wrote: > I think we're on the same page with all that. As clarified in [1], that's not a > big concern, I was referring to the changes required to integrate the auxbus > stuff. Well, I see this thread having the realization that things are not setup

Hi Arnaud, On Thu, Sep 17, 2020 at 05:21:02PM +0200, Arnaud POULIQUEN wrote: > Hi Guennadi, > > > -----Original Message----- > > From: Guennadi Liakhovetski <guennadi.liakhovetski at linux.intel.com> > > Sent: jeudi 17 septembre 2020 07:47 > > To: Arnaud POULIQUEN <arnaud.pouliquen at st.com> > > Cc: kvm at vger.kernel.org; linux-remoteproc at

Hi Arnaud, On Thu, Sep 17, 2020 at 05:21:02PM +0200, Arnaud POULIQUEN wrote: > Hi Guennadi, > > > -----Original Message----- > > From: Guennadi Liakhovetski <guennadi.liakhovetski at linux.intel.com> > > Sent: jeudi 17 septembre 2020 07:47 > > To: Arnaud POULIQUEN <arnaud.pouliquen at st.com> > > Cc: kvm at vger.kernel.org; linux-remoteproc at