[llvm-commits] [llvm] r104404 - /llvm/trunk/lib/Target/README.txt

[Chris Lattner]

On May 22, 2010, at 4:18 AM, Duncan Sands wrote:

> Hi Chris,
> 
>> +Another interesting case is that something related could be used for variables
>> +that go const after their ctor has finished.  In these cases, globalopt (which
>> +can statically run the constructor) could mark the global const (so it gets put
>> +in the readonly section).  A testcase would be:
>> +
>> +#include<complex>
>> +using namespace std;
>> +const complex<char>  should_be_in_rodata (42,-42);
>> +complex<char>  should_be_in_data (42,-42);
>> +complex<char>  should_be_in_bss;
>> +
>> +Where we currently evaluate the ctors but the globals don't become const because
>> +the optimizer doesn't know they "become const" after the ctor is done.  See
>> +GCC PR4131 for more examples.
> 
> isn't this what the invariant_start intrinsic and friends are for?  Dragonegg
> calls them in an analogous situation (to mark trampolines as constant after
> they have been initialized), and it works to some extent, though not as well as
> I would like.
> 

Could be.  I don't have time for deep thought on the matter right now, so I threw it into the readme :)