ping 3 On 24 March 2014 00:01, Rafael Espíndola <[email protected]> wrote: > ping 2 > > On 17 March 2014 06:59, Vassil Vassilev <[email protected]> > wrote: >> ping... >> >> On 03/11/2014 01:05 PM, Rafael Espíndola wrote: >>>> >>>> I am not sure I understand the intended semantics of the UnnamedAddr >>>> argument to GetOrCreateLLVMGlobal. Is it “this use does not care about the >>>> specific address”? Because, if so, the (existing) logic is completely >>>> backwards: we need to be *clearing* the flag on the global if the argument >>>> is ever *false*. And that seems like the most reasonable semantics, >>>> frankly. >>>> >>>> Also, the idea in the existing code that all runtime variables are >>>> unnamed_addr seems bogus to me. __dso_handle is a specific example of a >>>> variable whose address value *is* semantically important. This sort of >>>> thing would be important if there were any plausible transformations at all >>>> that involve unnamed_addr on external variable declarations. >>>> >>>> Also, the assertion is wrong: if something introduces a “runtime" >>>> declaration (e.g. by just declaring and using a global variable with the >>>> right name) before CodeGen emits its first intrinsic use of it, the >>>> declaration will not be marked unnamed_addr. >>>> >>>> So, basically, right now, this entire code path is useless and wrong. Is >>>> there a plan to apply it in situations where it wouldn’t be useless, i.e. >>>> to >>>> non-runtime user declarations? >>> >>> So, on how the patch is organized: >>> >>> * The structure the patch uses is that when the variable is first >>> created, its unnamed_addr is set to the value of the argument. >>> * We then check that no user expect that a variable is unnamed_addr >>> when in fact it isn't. I tried to make the check more strict by >>> asserting that Entry->getUnnamedAddr() == UnnamedAddr, but that fails >>> deep down in some objc cases that create runtime variables and access >>> them as regular ones. >>> >>> But to the more important point: Should we be adding unnamed_addr in >>> the first place? I am not sure. Back in >>> >>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110110/037796.html >>> Chris asked if we should. I could not find the entire discussion (the >>> patch that ended up being committed is simpler) and I am still not >>> sure exactly when CreateRuntimeVariable should be used. >>> >>> An alternative patch that simply never sets it in >>> CreateRuntimeVariable is attached. >>> >>> Cheers, >>> Rafael >> >>
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
