Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] function terminators"
2011 May 18
1
[LLVMdev] function terminators
On 5/17/2011 11:37 PM, Duncan Sands wrote:
> Hi George,
>
>> Does llvm provide a way to determine instructions that cause control to
>> leave functions? For example, return statements and exit statements cause
>> control exit out of function.
> there is no "exit" statement.
>
> I am looking for something similar to basic block
>> terminators.
2011 May 18
0
[LLVMdev] function terminators
Hi George,
> Does llvm provide a way to determine instructions that cause control to
> leave functions? For example, return statements and exit statements cause
> control exit out of function.
there is no "exit" statement.
I am looking for something similar to basic block
> terminators. Thanks.
Control can leave a function either (1) due to a return instruction
2011 Sep 16
2
[LLVMdev] How to duplicate a function?
Hi all,
Sorry for the inconvenient about the previous post. The files were not
attached. So I put them here again.
I am a newbie in LLVM and I am trying to replace the function like:
old function || new function
==============================
=========
int haha(int a) { int haha(int a, char* ID) {
===>
}
2006 Oct 31
2
[LLVMdev] callinst vs. invokeinst
What is the difference between a CallInst and an InvokeInst in LLVM? Is
an InvokeInst a CallInst that can throw an exception?
Thanks,
Ryan
2018 May 17
15
RFC: Removing TerminatorInst, simplifying calls
Going to keep this RFC short and to the point:
TerminatorInst doesn't pull its weight in the type system. There is
essentially a single relevant API -- iterating successors. There is no
other interesting aspect shared -- the interface itself just dispatches to
specific instructions to be implemented.
On the flip side, CallInst and InvokeInst have *massive* amounts of code
shared and struggle
2015 Mar 25
2
[LLVMdev] Instruction::mayThrow not handling invoke's?
While improving ADCE, i notice that for
declare i32 @strlen(i8*) readnone
define i32 @test() {
; invoke of pure function should not be deleted!
invoke i32 @strlen( i8* null ) readnone
to label %Cont unwind label %Other ; <i32>:1 [#uses=0]
Cont: ; preds = %0
ret i32 0
Other: ; preds = %0
%exn = landingpad {i8*, i32} personality i32 (...)*
@__gxx_personality_v0
2008 Sep 13
3
[LLVMdev] Duplicate Function with duplicated Arguments
I'm now writing a pass and I wanna ask a question about how to
duplicate the function and add duplicated arguments in llvm, for
example:
func(int a, char *b) -> func(int a, char *b, int a1, char *b1)
I'm now stuck at using "getOrInsertFunction" and how to handle
"getArgumentList", please share your opinion, thanks a lot!
James
2018 May 19
0
RFC: Removing TerminatorInst, simplifying calls
> On May 17, 2018, at 2:03 AM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> Going to keep this RFC short and to the point:
>
> TerminatorInst doesn't pull its weight in the type system. There is essentially a single relevant API -- iterating successors. There is no other interesting aspect shared -- the interface itself just dispatches to
2018 May 17
0
RFC: Removing TerminatorInst, simplifying calls
+1, sounds like a great idea
And if you're volunteering to do the work, even better! :)
Philip
p.s. Any reason we can't preserve a TerminatorInst type with an isa
function which just returns true for all our terminators but without
having terminators actually inherit from it? If so, we preserve the bit
of a "type safety" for a variable which is expected to always point to
2018 May 17
0
RFC: Removing TerminatorInst, simplifying calls
Are there any instructions that aren't terminators now, but will become
terminators with this change? I'm wondering if this is going to affect
reading old bitcode, and if so, how it will be handled.
-Krzysztof
On 5/17/2018 4:03 AM, Chandler Carruth via llvm-dev wrote:
> Going to keep this RFC short and to the point:
>
> TerminatorInst doesn't pull its weight in the type
2018 May 19
1
RFC: Removing TerminatorInst, simplifying calls
On Fri, May 18, 2018 at 10:26 PM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> > On May 17, 2018, at 2:03 AM, Chandler Carruth via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Going to keep this RFC short and to the point:
> >
> > TerminatorInst doesn't pull its weight in the type system. There is
>
2018 May 17
2
RFC: Removing TerminatorInst, simplifying calls
On Thu, May 17, 2018 at 10:32 AM Xinliang David Li <xinliangli at gmail.com>
wrote:
>
>
> On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Going to keep this RFC short and to the point:
>>
>> TerminatorInst doesn't pull its weight in the type system. There is
>> essentially a single
2008 Apr 16
2
[LLVMdev] Problems in removing a cloned instruction.
Hi all,
I am trying to write a pass where i am creating a clone of a
function (the only difference being, the new function returns void ,
instead of any value).
I am creating a new Function Type with a void return type (rest being
the same as original function), and using this i am creating a new
function body. Then, i clone the body of the old function into new
function, but when ever i
2013 Oct 10
2
[LLVMdev] Are there implicit rules or conventions for an llvm frontend to generate llvm IR?
Hi, this question might be a bit silly: apart from the language
reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are
there additional rules for a regular llvm frontend to generate llvm IRs?
There are a few cases that I got from clang/llvm-gcc/dragonegg when
compiling *C* source code into llvm IR:
1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for such
llvm
2018 May 17
0
RFC: Removing TerminatorInst, simplifying calls
On Thu, May 17, 2018 at 1:24 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> On Thu, May 17, 2018 at 10:32 AM Xinliang David Li <xinliangli at gmail.com>
> wrote:
>
>>
>>
>> On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Going to keep this RFC short and to the
2008 Apr 16
0
[LLVMdev] Problems in removing a cloned instruction.
Hi,
I'm gonna try to give some feedback, but I have only been working with LLVM
for a few days, so don't take what I'm saying without verifying :-)
> BasicBlock *ProgSlicer::CloneBasicBlock(const BasicBlock *BB,
> DenseMap<const Value*, Value*> &ValueMap,
> const char *NameSuffix, Function *F) {
>
> BasicBlock
2011 Jan 17
5
[LLVMdev] How to get the name and argument of a function
Hi everyone:
The code I am analyzing is :
int main()
{
int i = 0;
printf("hello world!");
printf( "%d" , i );
}
I want to get each place where printf is called, and the argument used
during that call.
so I write llvm pass code like:
void Myfunction( Function & F){
for( Function::iterator b = F.begin() , be = F.end() ;
2018 May 17
0
RFC: Removing TerminatorInst, simplifying calls
On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Going to keep this RFC short and to the point:
>
> TerminatorInst doesn't pull its weight in the type system. There is
> essentially a single relevant API -- iterating successors. There is no
> other interesting aspect shared -- the interface itself just dispatches to
2018 Nov 04
2
[RFC] Implementing asm-goto support in Clang/LLVM
(and FWIW, I'm currently trying to finish the patch that makes this a
reality... mostly hard because it has to unwind a loooot of complexity
we've built up due to not having this)
On Sat, Nov 3, 2018 at 5:47 PM Jeremy Lakeman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html
>
> TLDR; CallInst & InvokeInst
2008 Mar 16
2
[LLVMdev] improving the ocaml binding's type safety
Erick,
After some experimentation, I'd prefer the closed system. LLVM has
some type peculiarities like the commonality between CallInst and
InvokeInst. I find that the closed type system lets me express such
constraints more naturally. Expressing these constraints explicitly in
the open system involves annotating the C++ class hierarchy with extra
variants which are unnecessary in