Messages in this thread | | | From | Nick Desaulniers <> | Date | Tue, 12 May 2020 13:35:34 -0700 | Subject | Re: [PATCH] x86: support i386 with Clang |
| |
On Mon, May 11, 2020 at 1:03 PM David Woodhouse <dwmw2@infradead.org> wrote: > > On Mon, 2020-05-11 at 13:01 -0700, Linus Torvalds wrote: > > On Mon, May 11, 2020 at 12:52 PM Nick Desaulniers > > <ndesaulniers@google.com> wrote: > > > > > > Interesting approach. Researching __builtin_choose_expr, it looks > > > like it was cited as prior art for C11's _Generic keyword. > > > > Well, the thing that made me think that __builtin_choose_expr() would > > work is that unlike the switch statement, you absolutely _have_ to do > > the choice in the front end. You can't leave it as some kind of > > optimization for later phases, because the choice od expression ends > > up also determining the type of the result, so it isn't just a local > > choice - it affects everything around that expression. > > > > But clang still doesn't like that "qi" constraint with a (non-chosen) > > expression that has a "u64" type. > > > > I guess we can take the stupid extra cast, but I think it would at > > least need a comment (maybe through a helper function) about why "qi" > > needs it, but "ri" does not, and why the cast to "unsigned long" is > > needed, even though "clearly" the type is already just 8 bits. > > > > Otherwise somebody will just remove that "obviously pointless" cast, > > and gcc will eat the result happily, and clang will fail. > > I'm also mildly concerned that LLVM will start to whine about the 'ri' > case too. It's odd that it doesn't, even when GCC does.
Ah, sorry, it took me a while to understand what case you meant by this. I recall you pointing this out previously in https://bugs.llvm.org/show_bug.cgi?id=33587#c16, but at the time I simply wasn't well versed enough in inline asm to understand. The case you're referring to is 64b operands, "r" constraint, -m32 target. Yes, if I fix that: https://reviews.llvm.org/D79804, then this whole patch needs to be reworked. Back to the drawing board. -- Thanks, ~Nick Desaulniers
| |