search for: haoran

...cal variables needs to be kept alive, but 'g()' doesn't seem to require anything to be alive on the stack. I tried to manually add 'tail' to the emitted LLVM IR and it appears to work. Any idea how I could fix this and let clang automatically generate tail call? Thanks! Best, Haoran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201003/35e23c06/attachment.html>

...but lower quality instruction selection pass, resulting in the slower runtime? Could someone working on LLJIT clarify the difference in lowering passes between LLJIT and clang++? And if I were to change this behavior, which APIs should I look at to begin with? Thanks for your time! Best regards, Haoran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200903/72bd5fb0/attachment.html>

...symbol a declaration (drop the initializer, comdat and make the linkage external), but I'm wondering if it is expected behavior that LLJIT does not respect linkonce_odr specifier, since the documentation says LLJIT's symbol resolution should work as if I were running a normal linker. Best, Haoran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200807/a0c882c0/attachment.html>

..., optimized for different use cases, but I don't know any of the details. Can someone suggest a good introductory material that I should read to understand what are the pros and cons of each calling convention, and what should be the best calling convention for a given use case? Thanks! Best, Haoran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200925/f53f824a/attachment.html>

...ions to have 'available_externally' linkage, which I feel is the closest to what I want from my understanding of the document, though I'm not sure if this is the right approach, or if there is a better approach. Could you kindly give some pointers on this question? Thanks again! Best, Haoran David Blaikie <dblaikie at gmail.com> 于2020年6月12日周五 下午10:17写道： > On Fri, Jun 12, 2020 at 10:10 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > > > Hi David, > > > > Thanks for your quick response! > > > > I now understand the reason that inli...

...p when CodeGenOpt::None is given. It also doesn't show up when the host program (which uses the LLVM library) is compiled with "-O0". So it looks like some kind of use-after-free issue. Does any one have seen similar issues before, or have some idea on how to fix this? Thanks! Best, Haoran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201104/72679260/attachment.html>

...ird cases like this one? (3) Add 'target-features' attribute to all the functions I generated. Is this sufficient to prevent all weird cases like this one? Do I have the guarantee that the 'target-features' attribute of all bitcode files generated by clang++ are identical? Thanks! Haoran David Blaikie <dblaikie at gmail.com> 于2020年6月12日周五 下午9:54写道： > (+Eric Christopher for target attributes) > (+Lang Hames for JIT things) > > The problem is that those target features enable the compiler select > instructions that would only be valid if the target CPU has tho...

...ion epilogue is needed), one can actually change 'je .LBB0_2' to 'je g2()' directly, thus saving a jump. Is there any way I could instruct LLVM to do this? For my use case, it is acceptable to do this at any level (C++ level /IR level /MachineInst level is all fine). Thanks! Best, Haoran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201006/400bcc5a/attachment.html>

...delete all the attribute and MetadataNodes from the clang++-generated IR (and if yes, is that sufficient to prevent all those weird cases like this one)? I thought it was a bad idea because they provide more info to optimizer. If not, what is the proper way of handling this? Thanks! Best regards, Haoran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200612/b185c5a7/attachment.html>

On Thu, Aug 13, 2020 at 6:11 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Thanks for the insights David! > > For your first 3 points, is it correct to understand it as following: the external function prototypes are missing reliable information on whether the function throws and what exceptions it may throw (due...

On Thu, Aug 13, 2020 at 4:38 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Hello David and Sterling, thanks for the reply! > > I have no intention to heat up the discussion, please pardon me if I asked questions that might sound silly to you -- it's just that I truly didn't understand since I'm not exp...

On Thu, Aug 13, 2020 at 6:35 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Thanks for the reply. > >> Sorry, yes. No difference between explicit error handling and >> exceptions. The difference is in all the functions that don't have >> explicit error handling but (in the exception-using equival...

...all--the code is all there and explicit. All of this restricts what it can prove about the program. And the less it can prove, the less aggressive it can be. On Thu, Aug 13, 2020 at 3:13 PM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Aug 13, 2020 at 2:59 PM Haoran Xu via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > I have been long taught that exceptions are considered the bad parts in > the design of C++ language, and one should avoid using it since it's hard > to write exception-safe code...

...ode, from a LLVM backend developer's perspective? (2) In current LLVM design, is there still any optimization that is prevented by using exceptions? Or is the current LLVM already able to provide the same optimization quality for code using exceptions, compared with code that does not? Thanks! Haoran -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200813/fa71b679/attachment.html>

> > I did some experiments about a year ago with different hand-written > assembly implementations of error handling control flow patterns and it > was really hard to beat the checked return on recent Intel hardware. > This was a microbenchmark, so didn't see effects from increased cache > usage. That's a very interesting result. Thanks for the insights! Just out of