On 19/01/2024 08:14, Jiri Slaby wrote: > On 08. 01. 24, 19:19, Linus Torvalds wrote: >> On Mon, 8 Jan 2024 at 03:46, Jiri Slaby <jirislaby@xxxxxxxxx> wrote: >>> >>> CPP [M] drivers/media/pci/solo6x10/solo6x10-p2m.i >>> real 0m45,002s >>> >>> $ git revert 867046cc7027703f60a46339ffde91a1970f2901 >>> CPP [M] drivers/media/pci/solo6x10/solo6x10-p2m.i >>> real 0m11,132s >>> >>> $ git revert 4ead534fba42fc4fd41163297528d2aa731cd121 >>> CPP [M] drivers/media/pci/solo6x10/solo6x10-p2m.i >>> real 0m3,711s >> >> Ouch. Yeah, that's unfortunate. There's a lot of nested nasty macro >> expansion there, but that timing is excessive. >> >> Sparse actually complains about that file: >> >> drivers/media/pci/solo6x10/solo6x10-p2m.c:309:13: error: too long >> token expansion >> drivers/media/pci/solo6x10/solo6x10-p2m.c:310:17: error: too long >> token expansion >> >> and while that is a sparse limitation, it's still interesting. Having >> that file expand to 122M is not ok. >> >> In this case, I suspect the right thing to do is to simply not use >> min()/max() in that header at all, but do something like >> >> --- a/drivers/media/pci/solo6x10/solo6x10-offsets.h >> +++ b/drivers/media/pci/solo6x10/solo6x10-offsets.h >> @@ -56,2 +56,5 @@ >> >> +#define MIN(X, Y) ((X) < (Y) ? (X) : (Y)) >> +#define MAX(X, Y) ((X) > (Y) ? (X) : (Y)) >> + >> #define SOLO_MP4E_EXT_ADDR(__solo) \ >> @@ -59,4 +62,4 @@ >> #define SOLO_MP4E_EXT_SIZE(__solo) \ >> - max((..), \ >> - min(((..) - \ >> + MAX((..), \ >> + MIN(((..) - \ >> ..), 0x00ff0000)) >> @@ -67,4 +70,4 @@ >> #define SOLO_JPEG_EXT_SIZE(__solo) \ >> - max(.., \ >> - min(..) >> + MAX(.., \ >> + MIN(..) >> >> and avoid this issue. > > So can someone pick up 20240113183334.1690740-1-aurelien@xxxxxxxxxxx so that we are done with this? I see neither Hans, nor Linus got to take it yet. I replied here: https://lore.kernel.org/all/fd143cf8-5e3d-4d80-8b53-b05980558e45@xxxxxxxxx/ Either Linus can pick it up directly during the merge window, or it will appear in a media fixes PR once rc1 is released. Regards, Hans > >> That said, I'm sure this thing exists to a smaller degree elsewhere. I >> wonder if we could simplify our min/max type tests. > I assume we don't care with solo fixed? Hans pointed out ath11k too. Even if there is size increase in the preproc file, I don't see much of compile time increase there. > > thanks,
