search for: marceloabsousa

...me to where I should fix it? Kind regards, Marcelo On Tue, Jun 18, 2013 at 10:28 PM, Bill Wendling <wendling at apple.com> wrote: > Hi Marcelo, > > That should be fixed now at r184239. Sorry about the failure! > > -bw > > On Jun 17, 2013, at 6:16 AM, Marcelo Sousa <marceloabsousa at gmail.com> > wrote: > > > Hello, > > > > I'm getting an error when running opt with what seems to be a valid > bytecode file compiled from one the Linux Kernel files. > > The error is: > > opt: /home/scratch/llvm/lib/IR/Attributes.cpp:119: llvm::Stri...

Hi Marcelo, That should be fixed now at r184239. Sorry about the failure! -bw On Jun 17, 2013, at 6:16 AM, Marcelo Sousa <marceloabsousa at gmail.com> wrote: > Hello, > > I'm getting an error when running opt with what seems to be a valid bytecode file compiled from one the Linux Kernel files. > The error is: > opt: /home/scratch/llvm/lib/IR/Attributes.cpp:119: llvm::StringRef llvm::Attribute::getKindAsString...

Hello, I'm getting an error when running opt with what seems to be a valid bytecode file compiled from one the Linux Kernel files. The error is: opt: /home/scratch/llvm/lib/IR/Attributes.cpp:119: llvm::StringRef llvm::Attribute::getKindAsString() const: Assertion `isStringAttribute() && "Invalid attribute type to get the kind as a string!"' failed. I send you in attach

Very interesting, thanks for the forward! If you're interested in having a link posted on llvm.org, please email the llvmdev mailing list. -Chris On Jan 30, 2013, at 9:42 AM, Marcelo Sousa <marceloabsousa at gmail.com> wrote: > Dear all, > > I would like to share a paper I co-authored with Prof. Alper Sen. This > paper describes an algorithm to generate testbenches from SystemC > models represented with LLVM IR. It was accepted and presented at > International Conference on Ha...

Hello, According to the notes in [1] there was a plan to raise inline assembly blocks to the level of LLVM intrinsics or 'actual' LLVM IR. Is anyone aware of progress in this area? I'm aware that a complete solution in general is unlikely but a partial solution (that handles a subset of instructions directly mappable to the LLVM IR AST) could be very relevant. [1]

Hello, In the following code snippet: %tmp49 = call i64 asm "movq %gs:${1:P},$0", "=r,im,,~{fpsr},~{flags}"(i64* @kernel_stack) #6, !dbg !6625, !srcloc !5841 I would expect for the inline asm call to receive two arguments because of the ${1:P} corresponding to a %P1 that will append the $1 to %%gs:. Can someone explain why there is only one argument in this call? Moreover,

Dear all, I'm happy to share a recent publication on a bounded model checker for concurrent programs represented in LLVM IR that integrates the verification framework that I'm developing: Marcelo Sousa, and Alper Sen, LLVMVF: A Generic Approach for Verification of Multicore Software. Journal of Electronic Testing: Theory and Applications, September 2013. (

Dear all, I would like to share a paper I co-authored with Prof. Alper Sen. This paper describes an algorithm to generate testbenches from SystemC models represented with LLVM IR. It was accepted and presented at International Conference on Hardware/Software Codesign and System Synthesis (CODES/ISSS), 2012. A link to the paper is accessible from acm or Alper's website:

Hello all, The initial papers that describe the LLVM infrastructure mention the possibility of using LLVM for dynamic optimization. Is this functionality currently supported by the infrastructure? Additional information/pointers on this functionality or on the possibility of LLVM to be used as an infrastructure for dynamic software update would be highly appreciated. Kind regards, Marcelo

Hello, Is there a way to generate LLVM IR without constant expressions by promoting constant expressions to registers? e.g.: %tmp1 = tail call i8* @foo(i8* bitcast (i32* @x to i8*), i8* %tmp, i64 4) #1 would be converted to: %tmp1 = bitcast i32* @x to i8* %tmp2 = tail call i8* @foo(i8* %tmp1, i8* %tmp, i64 4) #1 I find quite inconvenient and redundant to maintain constant expressions when

I am interested in type-based verification of LLVM IR in the areas of certified compilation and software verification. It seems to me that the LLVM IR type system is rather informal in the sense that there is no paper with a proper formalization of the type rules, and for example, a proof of soundness for well-formedness of the code. I would like to know if you are aware of any work in this