similar to: Advice on memory copy instrumentation

Displaying 20 results from an estimated 10000 matches similar to: "Advice on memory copy instrumentation"

2020 Mar 27
2
Reliably mapping memcpy intrinsic
Similar to how `operator new(size)` can be overridden during linking, to capture and customize all memory allocation operations, I'd like to be able to capture all scenarios where memory is copied or moved. I've tried to use `--wrap memcpy` with some success, however I've noticed that in some instances (e.g. copying a small struct) the memcpy instruction in the IR is replaced with a
2019 Aug 06
2
Status of the New Pass Manager
I had a chance to try -print-after-all with NPM. It seems like there's still no output for the passes before objc-arc-contract (which is basically what I saw before.) Does anyone else see this? Are we talking about the same thing? *** IR Dump After ObjC ARC contraction *** *** IR Dump After Pre-ISel Intrinsic Lowering *** *** IR Dump After Expand Atomic instructions *** *** IR Dump After
2019 Aug 06
2
Status of the New Pass Manager
On 8/6/19 7:31 PM, Fedor Sergeev via llvm-dev wrote: > > > On 8/6/19 3:02 AM, Hiroshi Yamauchi via llvm-dev wrote: >> I had a chance to try -print-after-all with NPM. >> >> It seems like there's still no output for the passes >> before objc-arc-contract (which is basically what I saw before.) Does >> anyone else see this? >> >> Are we
2019 Aug 07
2
Status of the New Pass Manager
On 8/7/19 6:20 PM, Hiroshi Yamauchi wrote: > I basically run "clang > -fexperimental-new-pass-manager -print-after-all ..." > > It's conceivable that something is different in our setup or in clang > (from opt)... I'll see if I can reproduce it outside our setup. Does it depend on machine architecture? I generally use x86... regards,   Fedor. > > Thanks.
2019 Jul 11
3
Status of the New Pass Manager
I don't exactly remember when I last tried it and I didn't realize there was r342896. I'll check it out. Thanks. On Wed, Jul 10, 2019 at 1:14 PM Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > > Printing was implemented in r342896. > @Hiroshi: Are there specific issues or limitations you encountered with it? > > Cheers, > Philip > > On Wed, Jul 10,
2020 Mar 17
3
valid BasicAA behavior?
Hi Hal, In that case what is the best way to query whether there is a loop carried dependence between B[j] and A[j] at i-loop level? We were operating under the assumption of 'conservatively correct' behavior of alias analysis in the function scope? Thanks, Pankaj From: Finkel, Hal J. <hfinkel at anl.gov> Sent: Tuesday, March 17, 2020 11:50 AM To: Hiroshi Yamauchi <yamauchi at
2005 Apr 29
3
[LLVMdev] Java frontend
Hello, I have just read the LLVM paper (CGO'04) and thought it was an interesting project. And, I am wondering if there exists a Java frontend (that compiles Java bytecode to LLVM code) as the paper mentioned. If there is any, what is the status of it? Pardon me if this information is obviously provided somewhere in the LLVM web site. Best regards, Hiroshi Yamauchi Purdue University
2020 Mar 17
2
valid BasicAA behavior?
My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption
2019 Nov 08
2
Workflow to commit changes using git alone (?)
Hi Hiroshi, Thanks for that. I find “rebase” difficult to use. Maybe I don’t understand it, but it always causes a lot ‘conflicts’ that are very hard to fix according to my experience. I have another question though. LLVM requires that reviewed patches are pushed as a /single/ commit with a standardised message, particularly specifying the Differential Revision url as part of the commit message.
2018 May 14
3
more reassociation in IR
On Fri, May 11, 2018 at 7:20 PM Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> >> wrote: >>
2018 May 10
2
more reassociation in IR
On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Tue, May 8, 2018 at 11:15 AM
2018 May 12
3
more reassociation in IR
On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Wed, May 9, 2018 at 8:24
2020 May 12
2
RFC: Deleting git-svn folder (git-llvm, git-svnrevert, git-svnup)
Just push :) On Tue, May 12, 2020, 8:46 AM Hiroshi Yamauchi <yamauchi at google.com> wrote: > I was also using "git llvm push" to commit, sort of out of habit. What's a > recommended, alternative way to push? > > On Mon, May 11, 2020 at 11:57 AM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I was actually using `git
2019 Jul 10
2
Status of the New Pass Manager
-print-after-all is very useful for debugging and learning about LLVM. I would hope that would be implemented for the new PM before removing the old PM. I'd personally consider it a blocker. -Troy > -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Eric Christopher > via llvm-dev > Sent: Tuesday, July 09, 2019 7:40 PM > To:
2018 May 18
0
more reassociation in IR
I mentioned this earlier in the thread - I would like to see something like D41574 in the optimizer. It's optimizing code that no other pass does currently, and I don't see any other near-term proposal that gets us those optimizations. Omer, can you rebase that to trunk? I think a header has moved, so it doesn't build as-is. I'd like to know if it can catch the cases in D45842. If
2018 May 10
2
more reassociation in IR
On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Tue, May 8, 2018 at 11:15 AM Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Tue, May 8, 2018 at 10:38 AM, Hiroshi Yamauchi via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> ( >>> ​I came across this issue in
2018 May 12
0
more reassociation in IR
On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin > <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote: > > > > On Thu, May
2020 May 12
3
RFC: Deleting git-svn folder (git-llvm, git-svnrevert, git-svnup)
@Zola, Eric, I really feel the communication and reasoning here is problematic. From my perspective, you removed stuff "we don't need", ignoring whether it is used, and then let people figure out how to deal with the result. What I most dislike about the process most is how questions and concerns are then ignored or played down. Thanks,   Johannes On 5/12/20 2:10 PM,
2019 Mar 13
2
RFC: Getting ProfileSummaryInfo and BlockFrequencyInfo from various types of passes under the new pass manager
Overall seems fine to me. On 3/11/19 8:12 PM, Hiroshi Yamauchi wrote: > Here's a revised approach based on the discussion: > > - Cache PSI right after the profile summary in the IR is written in > the pass pipeline. This would avoid the need to insert > RequireAnalysisPass for PSI before each non-module pass that needs it. > PSI can be technically invalidated but unlikely
2019 Mar 04
2
RFC: Getting ProfileSummaryInfo and BlockFrequencyInfo from various types of passes under the new pass manager
On 3/4/19 10:49 PM, Hiroshi Yamauchi wrote: > > > On Mon, Mar 4, 2019 at 10:55 AM Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Sat, Mar 2, 2019 at 12:58 AM Fedor Sergeev > <fedor.sergeev at azul.com <mailto:fedor.sergeev at azul.com>> wrote: > > > > On 3/2/19 2:38 AM,