search for: katsuhiro

Displaying 5 results from an estimated 5 matches for "katsuhiro".

2013 Aug 03
2
[LLVMdev] bug of tail call optimization on x86 target
...though it's unlikely we'd > like 0x80000000 to be interpreted as positive, rather than negative if > it ever does occur. I totally agree with you. I rewrote my fix and made a test case according to your suggestion. All of them are included in the attached file. Thanks and regards, Katsuhiro Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: x86-tailcallopt-fix-2.diff Type: application/octet-stream Size: 2947 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130803/901297c7/attachment.obj>
2013 Aug 02
2
[LLVMdev] bug of tail call optimization on x86 target
...g points. Due to integral promotion, explicit conversion to signed integer is needed at those points. Eliminating tail calls (with arbitrary number of arguments) is mandatory for practical functional languages. I would appreciate it if this bug would be fixed in the next release. Best regards, Katsuhiro Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: x86-tailcallopt-fix.diff Type: application/octet-stream Size: 1790 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130803/b8ef92ae/attachment.obj>
2013 Aug 02
0
[LLVMdev] bug of tail call optimization on x86 target
Hi Katsuhiro, Thanks very much for taking the time to dig into this and produce a patch. Is there any chance you could make a couple of tweaks? > This bug is due to wrong computation of stack object indices by the > x86 backend. The attached patch indicates the wrong points. Due to > integral promo...
2013 Aug 04
0
[LLVMdev] bug of tail call optimization on x86 target
Hi Katsuhiro, > I rewrote my fix and made a test case according to your suggestion. > All of them are included in the attached file. Thanks very much for doing that and taking the time in the first place to make the patch. It looked good to me so I committed it in r187703. It'll automatically make...
2014 Jan 29
2
[LLVMdev] getelementptr on static const struct
...expected: define signext i8 @f() nounwind readnone ssp uwtable { ret i8 97 } I carefully read LLVM Language Reference Manual but I could not understand the difference of these two getelementptr expressions. Are these two getelementptr equivalent in the semantics of LLVM IR? Thanks, -- UENO, Katsuhiro