similar to: How to include abi and unwind tests in libcxx test suite in standalone mode

I just landed these patches: commit c55051eea5d3cd57abfd9727f519b670517704d9 Author: Louis Dionne <ldionne at apple.com> Date: Thu Jun 25 12:02:43 2020 -0400 [libunwind] Allow specifying custom Lit config files This is the libunwind counterpart of 0c66af970c80. commit 33c9c10d183371edc95fa936705bef56f55ab611 Author: Louis Dionne <ldionne at

Hi Quentin, thank you for the reply! This clears up a lot of the questions I was having. It seems like we should definitely invest some time in rewriting some of our legalization rules then! I also posted some questions further down below. I would appreciate getting your opinion on them. > Hi Dominik, > > I’ll do a brief reply here and if you want more information we can talk further

Hi Quentin, Am 08.10.20 um 21:17 schrieb Quentin Colombet: > Hi Dominik, > >> On Oct 8, 2020, at 5:03 AM, Dominik Montada >> <dominik.montada at hightec-rt.com >> <mailto:dominik.montada at hightec-rt.com>> wrote: >> >> Hi Quentin, >> >> thanks for picking up the conversation! >> >> > I think we should step back and

Hi Dominik, Thanks for your reply. In my case, the Defs is the cause of the problem. Or rather, it is part of the problem, because when I remove it from the instruction TableGen gives me a different error message which concerns a part which is deeper into the pattern tree, so at least it is able to proceed beyond that part of the pattern. I have also stepped TableGen inside gdb and

Hi, We're working on adding exception handling support for a downstream bare-metal target. I read through the LLVM exception handling docs [1] and went through some patches from other backends to understand what parts we need to implement. We're now at a point were it feels like it should work, but unfortunately exceptions are still not getting caught. Our target uses DWARF

Hi Daniel, Thanks for replying; I was hoping to get in touch with you on this issue. I had a look at how SelectionIDAG does it when generating the matcher table, and it does consider the implicit defs as additional output. Here is the match table generated for the pattern: /* 0*/ OPC_CheckOpcode, TARGET_VAL(ISD::SIGN_EXTEND), /* 3*/ OPC_MoveChild0, /* 4*/ OPC_CheckOpcode,

Hi all, After a recent upstream merge into our downstream sources we are suddenly encountering the freeze instruction in LLVM IR for div/rem pairs. This seems to be related to [1]. Our downstream target is GlobalISel only and unfortunately GlobalISel doesn't support this instruction yet, so most of our internal test-suite is now breaking due to GlobalISel not being able to translate this

Hi Quentin, Hi Amara, I was following your discussion on D75086 regarding declaring types as legal even if they are smaller than the actual register class (e.g. s16 and gpr32). We are working on a backend which only has 32 and 64-bit registers and we recently had a problem regarding exactly this where we had to declare G_UNMERGE_VALUES and G_MERGE_VALUES with a smaller type of <s32 as

Hi Matt, thanks for responding. I left a couple of comments down below. Am 24.03.20 um 18:26 schrieb Matt Arsenault: > >> On Mar 24, 2020, at 12:24, Dominik Montada via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> recently when working with GlobalISel we have often encountered cases in the legalizer where instructions could not be

Hi all, recently when working with GlobalISel we have often encountered cases in the legalizer where instructions could not be narrowed because the narrowing code relies on G_UNMERGE_VALUES and therefore requires the source type to be a multiple of the narrow type. Often times these instructions can be widened without any problem to a fitting type. This has us writing legalization rules like

Hi Quentin, thanks for picking up the conversation! > I think we should step back and check what we want before investing any time in some rewrite. That is a very fair point and I might have been getting ahead of myself in my last email. What I would like to see from RegBankSelect is to produce the mapping with the overall lowest cost. Keeping track of all different combinations of

Hi Quentin, thank you for the reply! I have a couple more questions that came up when I tried to implement this today. I hope you can help me out with this again! Am 09.03.20 um 23:31 schrieb Quentin Colombet: > I would expect that you could create a register class and register > bank for the special register. That way you have something to map to > when you do register bank select.

Hi, I am in the process of porting our target to GlobalISel, and have encountered a problem. Nearly all instructions in our instruction set make modifications to a CC register, and hence are defined as follows: let ..., Defs = [CCReg] in def shfts_a32_imm7: Instruction<(outs OurRC:$dst), ...>; What's more, many of these instructions have patterns where the instruction itself

[Cross-post to llvm-dev to make sure everybody relevant sees this] Hi, I'm currently trying to simplify the libc++/libc++abi/libunwind build systems and testing setup. In doing so, I am encountering issues related to "unusual" ways of building them. By unusual, I just mean "not the usual monorepo build with LLVM_ENABLE_PROJECTS". I would like to pin down what the set of

> On Feb 20, 2020, at 14:25, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > On 02/20, Louis Dionne via llvm-dev wrote: >> I know there has been significant discussion about "moving" from >> Phabricator to GitHub reviews and pull requests, etc. I'm not >> suggesting that we do anything in terms of global LLVM policy. >> However, as

> On Mar 3, 2020, at 17:16, Shoaib Meenai <smeenai at fb.com> wrote: > > `arc patch` should preserve the author information in the original commit, if there was any. At least it has in my experience. Yes, but I think people can upload raw patches to Phabricator without using `arc diff`. I know I ran into one of these just last week where I used Johannes' script (thanks!) and

Hi all, first of all thanks to Matt for hosting the round table yesterday and to everyone else for their time and the valuable discussions. As promised in the chat yesterday, here is the email regarding the legalizer / artifact combiner issue we talked about. I will send a separate email regarding the regbankselect discussion. In case someone on the list didn't attend the round table

Hi, I am observing the libcxx project can not be built without libcxxabi, but I thought libcxx should not depend upon other projects. Observed on x86. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200102/023ca21b/attachment.html>

> On Mar 3, 2020, at 18:48, Eric Christopher <echristo at gmail.com> wrote: > > I'm one of those people ;) That's not something to be proud of if you expect a maintainer to commit on your behalf. If you commit yourself, then whatever. Louis > > -eric > > On Tue, Mar 3, 2020 at 2:20 PM Louis Dionne via llvm-dev <llvm-dev at lists.llvm.org

Thanks Shoaib for a great summary. To summarize this as an answer to Louis' questions: 1. What is a "Standalone build"? What does it enable that a normal monorepo build can't? This means building any of the runtimes separately, where the runtime's CMakeLists.txt (e.g. path/to/my/llvm-project/libcxx/CMakeLists.txt) is the top-level one. The reason for using this variant is