On 2 March 2018 at 20:48, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Fri, Mar 02, 2018 at 06:53:49PM +0000, Dibyendu Majumdar wrote: >> On 2 March 2018 at 11:03, Christopher Li <sparse@xxxxxxxxxxx> wrote: >> > >> > That is just the memory operation convert to pseudo. >> > Sparse find out "b" has no dominating store (uninitialized), so >> > it just replace it with 0 value. >> > >> >> Does that make sense? I guess that if a var is uninitialized then the >> compiler is free to do what it likes, > > It make sense but only as far as you don't forget what you're doing. > The logic of this reasoning is: > - accessing an uninitialized var is undefined behaviour (UB) > - by definition after UB anything can happen > - since anything can happen the compiler can choose (to do) anything > - choosing 0 is as good as anything alse > > A more correct treatment is: > - use a specific value (UNDEF), unique for each var > - propagate this value as far as possible > - be very carefull with any simplification involving UNDEF > - at the end, issues an appropriate warning and/or replace it > the UNDEF by some appropriate value (for example 0) if this is desired. > Okay - I guess in my suggestion the size '0' signifies undefined or not 'register size' therefore not eligible for CSE. >> but in the previous version >> without size, this pseudo value will be considered 'equivalent' to any >> other pseudo value of 0 right? Is that correct? > > Indeed. > Anyway, once you have UB anything is 'correct'. > >> > The 64 bit one is b, the long type. >> > The 32 bit one is c, the int type. >> > >> > I already find out the place cause it: >> > The fix is here: >> >> Okay cool. However I was looking at a recent change that was done >> (last year) I think - to use a store to initialize an aggregate using >> value_pseudo() - see linearize_one_symbol() in linearize.c. Does that >> mean in the pre-sized code, such values would be considered same as >> everything else? >> >> In my view the aggregate initialization should be done using a >> dedicated OP code and not using store. > > This can be done, but this opcode would be semantically be a store > so it doesn't help to have another op for it. Thinking more about it - perhaps if a pseudo value of size 0 was used when the aggregate is bigger than register size then this would still be okay. I can see that when values are register size store makes sense. > >> But overall, I feel that we don't really care about sizes that are not >> 'register' size - do we? In reality we probably only care about 8, 16, >> 32, 64 bits. > > Even is 'pseudo' holds for 'pseudo-register' they are used for any 'values'. > Not sure I understood this point - I was suggesting that we only set pseudo value size when it makes sense to do so. >> However, that still leaves a question in my mind: >> >> a) Is it okay to assign a value 0 to uninitialized vars? > > As explained here above, it's OK but it's just a compiler choice > for something UB (and certainly not worse than any other). > >> b) If size is not present or is 0 - does that mean that the CSE logic >> will consider all these equivalent? That doesn't sound right to me. > > Sure, unless you special case it in CSE. I was wondering if the source of the bugs related to uninitialized var and CSE is this that the CSE doesn't know the value came from garbage. > >> I don't really understand how the CSE handles these but maybe - if you >> agree with above then CSE should ignore any pseudo value that is size >> 0? > > Currently, a size of zero is used for erroneous code, like incomplete > type and things like that (-1/~0 is also used for that). In such > situations CSE make no sense anyway, we just want to continue parsing > and give the best possible diagnostic for the remaining of the code. > I didn't follow - size 0 is used for pseudo values? > Unitialized var is different because, in full generality, you can't > (always) prove that the var is accessed *before* being initialized. > It's equivalent to the halting problem. It's very common that you > have code with some vars that are not initialized but which receive > a value before the var is used. In other words, the var is > uninitialized in the code but is initialized at run-time. > In short, the compiler can't prove that the access is UB or not. > -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
