similar to: [LLVMdev] Is sizeof(pointer) known in LLVM IR?

Looking through the IR documentation, I have been unable to establish if the size of a pointer value is knowable to an LLVM optimization pass. For an IR->IR optimization pass, is the pass allowed to assume anything about the size of a pointer value? Or is making such an assumption explicitly disallowed? Once target specific information gets introduced, I'm assuming that the size of

Hi, > which works but it produces LLVM IR code for all OpenCL intrinsics > implemented by libclc along with the kernel I am interested in, is their a > possibility to avoid this ? and only produce the llvm code for the kernel > required ? Mark all functions apart from the kernel entry points with the internal attribute and then run global dead code elimination (it should remove most

Hi Duncan, >>> and instcombine adds the explicit alignment according to >>>> the langref (pref alignment). >>> >>> Without an explicit alignment means the ABI alignment in the case of >>> loads/stores. >> >> Yes, that second step was clear. Assuming you meant the "preferential >> alignment", according to the langref.

Hi Clemens, > thanks for your comments. > >>> First, consider this function: >>> #include <stdint.h> >>> uint64_t foo(uint64_t *bar) { >>> *bar = 42; >>> return (uint64_t)bar & 3; >>> } >>> >>> Which is compiled to >>> define i64 @foo(i64* %bar) nounwind uwtable ssp {

Hi Clemens, > I'm instrumenting IR by replacing loads and stores by calls to a library, which > I have compiled to bitcode such that inlining can take place. My problem is: If > I could retain the alignment information on the load/store, this would open many > optimization opportunities after inlining. Unfortunately, I don't know how. > > After thinking about it, and

On 02/24/2014 11:27 AM, Andrew Trick wrote: > > On Feb 24, 2014, at 11:17 AM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >> >> On 02/24/2014 12:45 AM, Andrew Trick wrote: >>> >>> On Feb 21, 2014, at 10:37 AM, Philip Reames >>> <listmail at philipreames.com <mailto:listmail at

Hi Duncan, thanks for your comments. >> First, consider this function: >> #include <stdint.h> >> uint64_t foo(uint64_t *bar) { >> *bar = 42; >> return (uint64_t)bar & 3; >> } >> >> Which is compiled to >> define i64 @foo(i64* %bar) nounwind uwtable ssp { >> store i64 42, i64* %bar, align 8 >>

Hi all, I'm instrumenting IR by replacing loads and stores by calls to a library, which I have compiled to bitcode such that inlining can take place. My problem is: If I could retain the alignment information on the load/store, this would open many optimization opportunities after inlining. Unfortunately, I don't know how. After thinking about it, and trying different things, I now

On 7 July 2011 02:27, Kodakara, Sreekumar V <sreekumar.v.kodakara at intel.com> wrote: > I would like to know if there is an API/method that I can use to get the > name of the file being processed in a dynamically loaded function pass. In > other words, if I invoke a pass as follows > > opt  -load pass.so -hello  src.bc –o src.hello.bc > > where pass.so is a

I just realised I forgot to reply to this. Thanks for advise, it's good to know. Thanks, Dan Liew. On 30 August 2013 16:25, David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Aug 30, 2013 at 7:53 AM, Daniel Liew <daniel.liew at imperial.ac.uk> wrote: >> Hi, >> >> I'm trying to write a small piece of code that inlines all calls to a >> particular

On 02/24/2014 12:45 AM, Andrew Trick wrote: > > On Feb 21, 2014, at 10:37 AM, Philip Reames <listmail at philipreames.com > <mailto:listmail at philipreames.com>> wrote: > >> >> On 02/14/2014 05:55 PM, Philip Reames wrote: >>> Splitting out a conversation which started in "make DataLayout a >>> mandatory part of Module" since the

gcc picked up a couple of suspicious memset lengths which turned out to be real bugs. Signed-off-by: Anton Blanchard <anton at samba.org> --- usr/kinit/nfsmount/sunrpc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/usr/kinit/nfsmount/sunrpc.c b/usr/kinit/nfsmount/sunrpc.c index 0628cef..0a7fcf5 100644 --- a/usr/kinit/nfsmount/sunrpc.c +++

Commit-ID: 71a849a7e2d5e73321e986fa91d1f34b387e71ba Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=71a849a7e2d5e73321e986fa91d1f34b387e71ba Author: Anton Blanchard <anton at samba.org> AuthorDate: Tue, 3 Dec 2013 18:14:58 +1100 Committer: H. Peter Anvin <hpa at zytor.com> CommitDate: Tue, 3 Dec 2013 10:53:38 -0800 [klibc] nfsmount: memset uses sizeof

Hi Philip, Thank you very much for your comments. I think I’ve discovered a root cause. The problem was in linking bit code archive files with the module. At some point, std::set<Module*> is used and iterated over. I believe this was the reason why e.g. It worked consistently with ASLR turned off and produced non-deterministic output otherwise. I changed that bit to use vector instead and

On 20 December 2013 05:39, Daniel Liew <daniel.liew at imperial.ac.uk> wrote: > Hi Rafael and other LLVM devs, > > I'm currently upgrading a project that uses LLVM that links a bitcode > archive (a C library) with a module. Originally we used > Linker::LinkInFile() but that was removed by r172749. So I started > looking for an alternative and I found >

Dear wine user group I removed the whole installation under the root path and reinstalled the application to the user directory -thanks to mr. vitamin. But the effect is the same - the usb interface has not be enabled although the driver works correctly, see jstest /dev/input/js0 -> Driver version is 2.1.0. Joystick (IPACS Ikarus Gamecommander) has 7 axes (X, Y, Z, Rx, Ry, Rz, Throttle) and

On 10/23/2012 1:58 PM, John Criswell wrote: > Dear All, > > I'm enhancing a MachineFunctionPass that enforces control-flow > integrity. One of the things I want to do is to set the alignment of > an instruction (by adding NOPs before it in the MachineBasicBlock or > by emitting an alignment directive to the assembler) if it causes a > specific sequence of bytes to be

> On Jan 4, 2016, at 9:55 AM, Amaury SECHET via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > 2016-01-04 18:21 GMT+01:00 Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>>: > On 01/04/2016 07:32 AM, Amaury SECHET wrote: >> After a bit more investigation, it turns out that because %0 is stored into %1 (after

Hi Daniel, Thanks for your answer. > I am considering fixing the bug in the LLVM CommandLine library but is > going to be a long time before I can look at it. So don't wait for me > to do that. > Ok, ok, but, if you end up fixing this, please keep me post. > If you are really desperate to have the command line options in the > way you want they you may need to implement

On 01/04/2016 07:32 AM, Amaury SECHET wrote: > After a bit more investigation, it turns out that because %0 is stored > into %1 (after bitcast) and so %3 may have access to it and clobber it. Can you give a bit more context? I'm not sure which of the examples you're talking about. > > After a bit of thought, it is correct in the general case, but > definitively something