From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
To: Behan Webster <behanw@converseincode.com>
Cc: Felipe Balbi <balbi@ti.com>,
davem@davemloft.net, linux-usb@vger.kernel.org,
netfilter-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
Compiling the Linux Kernel with Clang/LLVM
<llvmlinux@lists.linuxfoundation.org>
Subject: Re: [PATCH V2 2/3] Remove VLAIS usage from gadget code
Date: Tue, 4 Dec 2012 23:24:38 +0100 [thread overview]
Message-ID: <20121204222438.GA7624@breakpoint.cc> (raw)
In-Reply-To: <50BCF61D.5000707@converseincode.com>
On Mon, Dec 03, 2012 at 07:57:33PM +0100, Behan Webster wrote:
> However, in order to approximate what gcc is doing in code, obviously
> some math is required. The thought was that macros would hide the
> worst of it, trying not to obfuscate what was actually being done.
Why hide? The thing that is done here is setting up pointers and keep this
struct as a container. It is never used again, just freed. Therefore I would
suggest to remove and do something different.
> One of the project members came up with this alternative. How about
> something like this? Less math, though more string pasting. When
> compiled, the unused variables get optimized away. Otherwise the
> memory packing is identical to using VLAIS in gcc.
>
> #define vla_struct(structname) size_t structname##__##next = 0
> #define vla_struct_size(structname) structname##__##next
>
> #define vla_item(structname, type, name, n) \
> type * structname##_##name; \
> size_t structname##_##name##__##pad = \
> (structname##__##next & (__alignof__(type)-1)); \
> size_t structname##_##name##__##offset = \
> structname##__##next + structname##_##name##__##pad; \
> size_t structname##_##name##__##sz = n * sizeof(type); \
> structname##__##next = structname##__##next + \
> structname##_##name##__##pad +
> structname##_##name##__##sz;
>
> #define vla_ptr(ptr,structname,name) structname##_##name = \
> (typeof(structname##_##name))&ptr[structname##_##name##__##offset]
>
>
> Then you can do something like this that looks vaguely struct-like:
>
> vla_struct(foo);
> vla_item(foo, char, vara, 1);
> vla_item(foo, short, varb, 10);
> vla_item(foo, int, varc, 5);
> vla_item(foo, long, vard, 3);
> size_t total = vla_struct_size(foo);
> char buffer[total];
>
> vla_ptr(buffer, foo, varc);
> foo_varc = 1;
I prefer to try to rewritte the code in the gadget in a different manner
before using macro magic. I guess most people around here think that extensive
usage of macros equals giving a gun to a chimpanzee. It may work for a while
and may even look cute in the eye of the gun sponsor. However once it fires…
> I've been profiling some sample code around this implementation
> comparing it between compilers, and it approximates the code size and
> speed of using VLAIS in gcc (especially with -O2). It actually
> performs better than the previously proposed macros.
I'm not concerned about speed here. This is an one time setup.
> But certainly if anyone has a solution which works for everyone, then
> I'm more than happy to adopt it. The LLVM community has made quite a
> few changes in order to help get Linux working with clang. However,
That is nice to hear. Besides gcc there is the icc.
> VLAIS is not something they are willing to accept (for various
> reasons). There are other patches to LLVM that are still working
Is this not described in C99 6.7.2.1p16?
> their way upstream that are required to be able to compile Linux as
> well.
I hope the other are "simple" to get in :)
>
> Behan
>
Sebastian
next prev parent reply other threads:[~2012-12-04 22:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-30 21:18 [PATCH V2 0/3] Removing the use of VLAIS from USB Gadget and netfilter Behan Webster
2012-10-30 21:18 ` [PATCH V2 1/3] Helper macros used for replacing the use of VLAIS Behan Webster
2012-10-30 21:18 ` [PATCH V2 2/3] Remove VLAIS usage from gadget code Behan Webster
[not found] ` <1351631937-21455-3-git-send-email-behanw-k/hB3zQhLwledRVtV/plodBPR1lH4CV8@public.gmane.org>
2012-10-31 13:28 ` Felipe Balbi
[not found] ` <20121031132838.GQ10998-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-10-31 15:33 ` Behan Webster
[not found] ` <509144C0.8000601-k/hB3zQhLwledRVtV/plodBPR1lH4CV8@public.gmane.org>
2012-11-01 7:21 ` Felipe Balbi
2012-11-01 15:03 ` David Miller
[not found] ` <20121101072116.GA32013-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-12-03 11:57 ` Sebastian Andrzej Siewior
[not found] ` <20121203115706.GA4760-E0PNVn5OA6ohrxcnuTQ+TQ@public.gmane.org>
2012-12-03 18:57 ` Behan Webster
2012-12-04 22:24 ` Sebastian Andrzej Siewior [this message]
[not found] ` <20121204222438.GA7624-E0PNVn5OA6ohrxcnuTQ+TQ@public.gmane.org>
2012-12-04 23:50 ` Behan Webster
2012-12-05 23:48 ` [llvmlinux] " Bryce Lelbach
2012-10-30 21:18 ` [PATCH V2 3/3] Remove VLAIS usage from netfilter Behan Webster
2012-10-31 16:45 ` [PATCH V2 0/3] Removing the use of VLAIS from USB Gadget and netfilter David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121204222438.GA7624@breakpoint.cc \
--to=sebastian@breakpoint.cc \
--cc=balbi@ti.com \
--cc=behanw@converseincode.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=llvmlinux@lists.linuxfoundation.org \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).