similar to: How to get the destination in a LoadInst

Displaying 20 results from an estimated 5000 matches similar to: "How to get the destination in a LoadInst"

2018 Dec 12
2
How to get the destination in a LoadInst
Hi, I would like to get the '5'. I would like to know where the loaded value is stored. I don't know which method I should use of the LoadInst class. Hope this clarifies Thanks On Wed, Dec 12, 2018, 20:37 Doerfert, Johannes Rudolf <jdoerfert at anl.gov wrote: > The LoadInst is %5. I'm not sure what you mean by reference though. > > On 12/12, Alberto Barbaro via
2018 Dec 12
2
How to get the destination in a LoadInst
Thanks Joshua and Michael, Just to to clarify, I'm experimenting with the Interpreter class and observing the instructions that are executed by it. Just for becoming more confident with LLVM in general I'd like for each instruction to access to the various parts of it. In this instance I would like to access to the %Name that is shown in the textual representation. When I call
2019 Jan 27
2
(no subject)
Hi, All good points and jokes in your email :) My final goal is the get the value of %8 at runtime. So considering the program is called argv I would like to execute something like ./argv 22 and get the value of argv[0]. Is it possible? So far I have the address where the parameter at position 0 in store but I'd like to read the value and print it. I hope it is clear now Thanks again On
2019 Jan 20
3
(no subject)
Hi all, I have the following C code: #include<stdio.h> int main(int argc, char *argv[]) { printf("%s\n", argv[0]); return argc; } that generates the following IR for the main function: ; Function Attrs: noinline nounwind optnone uwtable define i32 @main(i32, i8**) #0 { %3 = alloca i32, align 4 %4 = alloca i32, align 4 %5 = alloca i8**, align 8 store i32 0, i32*
2020 May 18
4
LLVM Alias Analysis Technical Call - Doodle Poll
To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC please use this information: Meeting URL https://bluejeans.com/643493129?src=join_info Meeting ID 643 493 129 Want to dial in from a phone? Dial one of the following numbers: +1.312.216.0325 (US (Chicago)) +1.408.740.7256 (US (San Jose)) +1.866.226.4650 (US Toll Free) (see all numbers -
2020 May 13
2
LLVM Alias Analysis Technical Call - Doodle Poll
Hi, everyone, We've had a number of discussions recently, including on the Flang technical call, about potential improvements to LLVM's alias analysis to support handling restrict and restrict-like semantics. We would like to try having a call to discuss these issues further. Please, if you're interested in joining, indicate your availability (prior to the end of this week):
2020 May 21
2
LLVM Alias Analysis Technical Call - Doodle Poll
Great, thanks! Are you planning on just talking about these things with slides? Do we have other things to which we can link for people to read? -Hal Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ________________________________ From: Tarique Islam <tislam at ca.ibm.com> Sent: Thursday, May 21, 2020 8:19:31 AM To:
2019 Nov 12
2
Full restrict support - status update
Hi Johannes et al, > -----Original Message----- > From: Doerfert, Johannes <jdoerfert at anl.gov> [..] > On 11/06, Jeroen Dobbelaere wrote: > > >From: Alexey Zhikhartsev > > [..] > > > We would love to see your patches merged as soon as possible, so I was > wondering: do you think the lack of bitcode support will prevent that from > happening? >
2020 Jun 24
4
LLVM Alias Analysis Technical Call - New Doodle Poll
Hi, everyone, We had a great call last month, and progress is definitely being made on several fronts. The notes from our last call are available here: https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit#heading=h.vpxs8lkuxy79 and, also, pasted below. DOODLE POLL: As we discussed on our last call, I would like to schedule a regular call to discuss
2013 Jan 28
0
[LLVMdev] Value* to Instruction*/LoadInst* casting
The compilation error is : `error: ‘LD100’ was not declared in this scope.` On Mon, Jan 28, 2013 at 11:31 AM, Alexandru Ionut Diaconescu < alexandruionutdiaconescu at gmail.com> wrote: > Hello everyone, > > Can you please tell me if it is possible in LLVM to cast a `Value*` to an > `Instruction*/LoadInst*` if for example `isa<LoadInst>(MyValue)` is true? > In my
2019 Mar 23
4
Generating object files more efficiently
It is my actual target architecture ________________________________ From: Doerfert, Johannes <jdoerfert at anl.gov> Sent: Saturday, March 23, 2019 1:30 PM To: J S Cc: via llvm-dev Subject: Re: [llvm-dev] Generating object files more efficiently I copied "-march=XYZ" from your original email, you have to replace it with your actual target architecture or simply drop it.
2013 Jan 28
1
[LLVMdev] Value* to Instruction*/LoadInst* casting
Hi Alexandru, > The compilation error is : `error: ‘LD100’ was not declared in this scope.` > > On Mon, Jan 28, 2013 at 11:31 AM, Alexandru Ionut Diaconescu < > alexandruionutdiaconescu at gmail.com> wrote: > >> Hello everyone, >> >> Can you please tell me if it is possible in LLVM to cast a `Value*` to an >> `Instruction*/LoadInst*` if for example
2013 Jan 28
5
[LLVMdev] Value* to Instruction*/LoadInst* casting
Hello everyone, Can you please tell me if it is possible in LLVM to cast a `Value*` to an `Instruction*/LoadInst*` if for example `isa<LoadInst>(MyValue)` is true? In my particular piece of code: Value* V1 = icmpInstrArray[i]->getOperand(0); Value* V2 = icmpInstrArray[i]->getOperand(1); if (isa<LoadInst>(V1) || isa<LoadInst>(V2)){ ...
2013 Jan 28
0
[LLVMdev] Value* to Instruction*/LoadInst* casting
Alexandru Ionut Diaconescu wrote: > Hello everyone, > > Can you please tell me if it is possible in LLVM to cast a `Value*` to > an `Instruction*/LoadInst*` if for example `isa<LoadInst>(MyValue)` is > true? http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast-templates In my particular piece of code: > > Value* V1 =
2019 Mar 23
2
Generating object files more efficiently
-march for clang and -march for llc do different things unfortunately. -march for clang at least on x86 is the same as -mcpu in llc. Which is an artifact of gcc compatibility. ~Craig On Sat, Mar 23, 2019 at 1:40 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Oh, my bad. > > > Idk why llc seems to know that architecture but clang does not. > >
2019 Jun 06
2
Webpage to track implementation status of OpenMP features
Yes, I understand. I just don't understand why there are 15 review links. as to the format of the list, we previously had a list of feature for 4.5 (before it was fully supported), we can reuse this old format. Best regards, Alexey Bataev > 6 июня 2019 г., в 19:12, Narayanaswamy, Ravi <ravi.narayanaswamy at intel.com> написал(а): > > Alexey, > Johannes want to put all
2020 Jan 27
3
Custom Alloca implementation
---Adding llvm-dev list to CC--- Hi Alberto, Thanks for your prompt reply. Actually, I need this information(about total allocation size and object structure) on runtime, so that is why I was planning to encode this info and store it in the memory itself. Regards, Udit On Mon, Jan 27, 2020 at 7:05 PM Alberto Barbaro <barbaro.alberto at gmail.com> wrote: > Hello Udit, > I'm not
2019 Mar 13
3
[RFC] Late (OpenMP) GPU code "SPMD-zation"
Johannes, did you try it on AMD GPUs? If not, I think it might be early to claim it as a general interface for NVidia/AMD GPUs. I'm ok, if you want tointroduce a basic class for the GPU-specific codegen, but it must be done step-by-step and thoroughly tested and reviewed. Theremightbe some parts, common with NVPTX codegen. You can put the commonfunctions into a base class and remove them from
2019 Jun 06
2
Webpage to track implementation status of OpenMP features
I don't know where it comes from, currently there is just 2 patches with the new functionality : mapper implementation in clang and in the runtime. Plus the patch for unified memory. Best regards, Alexey Bataev > 6 июня 2019 г., в 19:03, Doerfert, Johannes <jdoerfert at anl.gov> написал(а): > >> On 06/06, Alexey Bataev via llvm-dev wrote: >> Hmm, it is interesting.
2020 Jan 28
2
Global removal pass - potential for improvement?
It's not about the pointer per se but the object it points to. If we have 2 objects of which we know the minimal/maximal size respectively we can sometimes conclude the objects must be different. Accesses to different objects do not alias. We already use that logic but we don't have the upper bound size as an attribute. Hence, it only applies if we know the exact size, basically is we see