search for: wenhan

On May 22, 2011, at 8:49 PM, Wenhan Gu wrote: > I know __builtin_va_list is target-specific, and > ARM has typedef void* __builtin_va_list; > X86 has typedef char* __builtin_va_list; > > > It seems they can be treated as the same prototype,i.e.. void*, at the header level. > What I want to ask is: > > If...

...re has been > work on such reversible transformations done (I can't recall where atm), but > that was only in very simple cases that could be described by regular > expressions. > > So the short answer is "no." > > -Joshua > > On Wed, May 4, 2011 at 9:16 PM, Wenhan Gu <nowar100 at gmail.com> wrote: > >> Hi all, >> >> I have a source code: >> int* p = malloc(...); >> >> After translating to llvm::Module, We can know the source code did not >> call free. >> I know we can hack this into Module. >> &g...

Hi all, in this case: ... int* p = ... int* q = p; ... How can I know that data-flow from p to q, i.e., which LLVM pass of header files could I use? Thank you all. -- Best regards, Wen-Han -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110430/a9164c60/attachment.html>

...t X86 use *char ** ? Seems ARM uses void * since its spec said that. But X86? I cannot find any reason or spec to specify why X86 uses char *, not void * directly? Could anyone give me some hints? Thanks a lot. 2011/5/23 John McCall <rjmccall at apple.com> > On May 22, 2011, at 8:49 PM, Wenhan Gu wrote: > > I know __builtin_va_list is target-specific, and > ARM has typedef void* __builtin_va_list; > X86 has typedef char* __builtin_va_list; > > It seems they can be treated as the same prototype,i.e.. void*, at the > header level. > What I want to ask is: > >...

Hi all, I know __builtin_va_list is target-specific, and ARM has typedef void* __builtin_va_list; X86 has typedef char* __builtin_va_list; It seems they can be treated as the same prototype,i.e.. void*, at the header level. What I want to ask is: If I write a program use "typedef *void** __builtin_va_list" on X86, and run it. Would I face any problem on run-time? I think it won't

...re has been > work on such reversible transformations done (I can't recall where atm), but > that was only in very simple cases that could be described by regular > expressions. > > So the short answer is "no." > > -Joshua > > On Wed, May 4, 2011 at 9:16 PM, Wenhan Gu <nowar100 at gmail.com> wrote: > >> Hi all, >> >> I have a source code: >> int* p = malloc(...); >> >> After translating to llvm::Module, We can know the source code did not >> call free. >> I know we can hack this into Module. >> &g...

...ch for LTO, named WHOPR, which can reduce memory usage well. I know LLVM has good LTO and gold plugin support, but it will link Modules into a big one, that causes lots of memory usage while optimization. Did LLVM have any plan on WHOPR or something like that in future? Thanks! -- Best Regards, WenHan Gu (Nowar) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130322/89fd34f0/attachment.html>

Dear all, AFAIK, ARM EHABI is not ready for both asm and obj emitter. Some people including me what to implement them. My question is, to avoid duplicate effort, does someone take charge of this part? or does anyone is already implementing this currently? BTW, any suggestion on this effort? I'm very appreciated! Thanks in advance! -- Best regards, Wen-Han Gu (Nowar) -------------- next

Hi all, I have a source code: int* p = malloc(...); After translating to llvm::Module, We can know the source code did not call free. I know we can hack this into Module. But my question is, could we hack it back to source code? After fixing, the source will become: int *p = malloc(...); free(p); Is this feasible? Thanks all very much. -- Best regards, Wen-Han -------------- next part

Dear Renato and Anton, Big thanks to your help. Those references are very helpful! BTW, After I applying this patch from Logan Chien, I pass some examples on ARM assembly emission. It seems good to me. http://llvm.org/bugs/show_bug.cgi?id=7187#attach_9161 For object file emission, The first thing is making MC generate correct .ARM.exidx and .ARM.extab. I will keep tracing that. Thanks!