[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-sparse
Subject:    Re: [sparse] PATCH: minor fix for initializer assign
From:       Linus Torvalds <torvalds () osdl ! org>
Date:       2004-04-21 19:00:35
Message-ID: Pine.LNX.4.58.0404211140410.1775 () ppc970 ! osdl ! org
[Download RAW message or body]



On Wed, 21 Apr 2004, Christopher Li wrote:
> 
> One thing I notice that if the source contain some thing
> that sparse don't agree. Evaluation will exit early and linearizion
> will see some abnormal AST comes in. I think may be sparse
> need to have some way to report error just like
> normal compiler does. Error won't stop evaluation, but don't
> brother to start linearizion on errors.

Yes. We should just exit on any syntax or type evaluation errors.  The 
only reason I made everything a "warning" instead of hard errors is that 
it historically gave much better coverage that way (ignore the stuff you 
don't understand, and continue giving warnings for the rest).

These days the front-end side is good enough that we could make errors
there fatal (and either stop immediately, or stop after that particular
pass has finished).

> > I agree that it is a special case, and that it's an optimization that 
> > later back-end processing would have noticed _anyway_ through constant 
> > propagation, but there is one really important reason for it: the kernel 
> > really wants
> > 
> > 	__builtin_constant_p()
> > 
> > to work inside inline functions on the arguments, and I want to be able to 
> > evaluate that early.
> 
> I am toying with the idea that do the pointer game in the MIR.
> The inline function will copy and insert basic blocks instead
> of C statement. It can do a lot of things otherwise be hard
> in the AST. But it might slow down the checking though.

The checking is one of the more important parts for me, that was why the
whole project started in the first place, after all. And one of the
reasons I want to do certain simplifications (like trivially unreachable
code etc) early is that I want to be able to do the warning checks early. 

But I don't see anything fundamental:

> Is there any existing checking hard to perform in the  MIR?
> Checking assign inside conditional expression cross my mind.

Agreed. On the other hand, that one is purely syntactic, and could be 
moved into the parse phase, ie even earlier than it is now. So if you want 
to make it linearize early, I'm ok with it.

What I'm _not_ ok with is to waste memory, though. In particular, I want
things to be evaluated as lazily as possible - I did some statistics early
on, and many (most?) C compilation unit have _more_ stuff in header files
(that seldom ends up being used) than they have in the "proper" C file
itself.

That is one of the reasons why I keep things in the highest possible
format until I need to actually look closer - symbols aren't actually
fully evaluated for their type until they are actually _used_, and a
unused inline function will never ever be evaluated or expanded at all, it
will have been made into a parse tree and never touched afterwards.

So I'd be very opposed to making linearization happen _too_ early, for 
example. I don't want to linearize inline functions before they are used 
etc.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]