similar to: Debugging clang with debugger breakpoints ?

Hi David, Thank you for your help. Please, can you elaborate on this?. The command line that I get with -### starts with this: clang version 9.0.1 (https://github.com/llvm/llvm-project.git 6e38ee067b8fa08792f551fb565bbb8ada4864b1) Target: msp430 Thread model: posix InstalledDir: /Users/joan/LLVM-9/llvm-project/build/Debug/bin "/Users/joan/LLVM-9/llvm-project/build/Debug/bin/clang"

Hi David, Thank you for your patience but I still don’t get it: I don’t see how that is a “command”, as it’s just a list of strings that state command options. I know how to use the debugger, this is what I attempt to debug: clang --target=msp430 -emit-llvm -c -S -Oz main.c The debugger works fine, but only on the main thread. However breakpoints do not work with the code that was invoked

Sorry Zach, my apologies. I understood now what you mean. I tried and it works!. But now I found that LLVM_DEBUG statements and other output to the console doesn’t show. How do I get that back?. Thanks John > On 4 Nov 2019, at 22:26, Zachary Turner <zturner at roblox.com> wrote: > > You hit Reply on my email but then addressed David. So I want to make sure you saw my

Hi David, I understand what you say, but have you actually read my messages? I don’t think so, Anyway, I will repost the question in case someone else can help. Thanks John > On 4 Nov 2019, at 22:18, Zachary Turner <zturner at roblox.com> wrote: > > > > On Mon, Nov 4, 2019 at 1:11 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

Hi John, On Tue, 14 May 2019 at 17:51, Joan Lluch <joan.lluch at icloud.com> wrote: > This problem is also shared by the MSP430 target, and it’s very easy to reproduce by just compiling the code that I posted before. That's some good detective work; it definitely explains what you're seeing. Since MSP430 is affected it would probably be pretty easy to upstream an alignment-aware

Hi Eli, First of all, please I would appreciate that you try to not confuse my limited use of English with stupidity or lack or criteria in other subjects. I’m not English native, so please keep that in mind. You have been significantly helpful in the recent past so please keep on. Interestingly, you made a mention of a related but not identical issue. It is true that most (or all) processors

Hi Sanjay, Thanks for your reply. > So yes, the IR optimizer (instcombine is the specific pass) sometimes turns icmp (and select) sequences into ALU ops. Instcombine is almost entirely *target-independent* and should remain that way. The (sometimes unfortunate) decision to create shifts were made based on popular targets of the time (PowerPC and/or x86), and other targets may have suffered

Hi Joan, On Mon, 13 May 2019 at 18:01, Joan Lluch <joan.lluch at icloud.com> wrote: > After looking at it a bit further, I think this is a Clang thing. Clang issues “align 2” if the struct has at least one int (2 bytes), but also if the entire struct size is multiple of 2. For example a struct with 4 char members. In these cases the LLVM backend correctly creates word sized load/stores

Hi all, > On 2 Oct 2019, at 14:34, Sanjay Patel <spatel at rotateright.com> wrote > Providing target options/overrides to code that is supposed to be target-independent sounds self-defeating to me. I doubt that proposal would gain much support. > Of course, if you're customizing LLVM for your own out-of-trunk backend, you can do anything you'd like if you're willing to

On Mon, Sep 30, 2019 at 11:52 AM Joan Lluch <joan.lluch at icloud.com> wrote: > > Hi Roman, > > Is "test" actually an implementation of a 64-bit-wide multiplication > compiler-rt builtin? > Then i'd think the main problem is that it is being optimized in the > first place, you could end up with endless recursion… > > > No, this is not a compiler-rt

For any of the examples shown below, if the logical equivalent using cmp + other IR instructions is no more than the number of IR instructions as the variant that uses shift, we should consider reversing the canonicalization. To make that happen, you would need to show that at least the minimal cases have codegen that is equal or better using the cmp form for at least a few in-tree targets. My

As before, I'm not convinced that we want to allow target-based enable/disable in instcombine for performance. That undermines having a target-independent canonical form in the 1st place. It's not clear to me what the remaining motivating cases look like. If you could post those here or as bugs, I think you'd have a better chance of finding an answer. Let's take a minimal example

Hi Eli, Thanks for pointing to the CTLZ_ZERO_UNDEF “LibCall” implementation. I have not it in the version that I am currently using, so it’s nice to know that it’s implemented now. Incidentally, the CTLZ… implementation is IDENTICAL to what I am proposing for the Shifts. This is not just adding support for “out-of-tree-targets”, but giving consistency to the fact that we have perfectly defined

To be honest, I don’t either know what really happens under the hood when CMake creates the xCode project for CLang+LLVM. But there’s something really explicit going on there, because the project as it’s shown in xCode does not have the same file grouping structure than the actual physical folders. Not only the project file grouping doesn't match the physical folder locations, but the group

On Sun, Sep 29, 2019 at 3:35 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sanjay, > > Actually, the CodeGenPrepare::optimizeSelectInst is not doing the best it could do in some circumstances: The case of “OptSize" for targets not supporting Select was already mentioned to be detrimental. > > For targets that actually have selects, but branches

For the MSP430 example, I'm guess its InstCombiner::transformSExtICmp or InstCombiner::transformZExtICmp ~Craig On Mon, Sep 30, 2019 at 2:21 PM Support IMAP <support at sweetwilliamsl.com> wrote: > Hi all, > > Ok, I just found a much simpler example of the same issue. > > Consider the following code > > int cmpge32_0(long a) { > return a>=0; > } >

Changing the order of the checks in CodeGenPrepare::optimizeSelectInst() sounds good to me. But you may need to go further for optimum performance. For example, we may be canonicalizing math/logic IR patterns into 'select' such as in the recent: https://reviews.llvm.org/D67799 So if you want those to become ALU ops again rather than branches, then you need to do the transform later in

On Wed, Nov 13, 2019 at 12:26 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi All, > > In relation to the subject of this message I got my first round of patches successfully reviewed and committed. As a matter of reference, they are the following: > > https://reviews.llvm.org/D69116 > https://reviews.llvm.org/D69120 >

Hi All, While implementing a custom 16 bit target for academical and demonstration purposes, I unexpectedly found that LLVM was not really ready for 8 bit and 16 bit targets. Let me expose why. Target backends can be divided into two major categories, with essentially nothing in between: Type 1: The big 32 or 64 bit targets. Heavily pipelined with expensive branches, running at clock

Hi, In relation to this subject, I have submitted bug reports, baseline tests, and patches that go towards this goal: https://bugs.llvm.org/show_bug.cgi?id=43542 <https://bugs.llvm.org/show_bug.cgi?id=43542> https://bugs.llvm.org/show_bug.cgi?id=43559 <https://bugs.llvm.org/show_bug.cgi?id=43559> https://reviews.llvm.org/D69099 <https://reviews.llvm.org/D69099> (baseline