[PATCH] Global merge on constants

[Quentin Colombet]

Ping?

-Quentin

On Feb 27, 2013, at 9:55 AM, Quentin Colombet <qcolombet at apple.com> wrote:

> Hi Duncan,
> 
> Does it mean that the current behavior of global merge is wrong or is this unnamed_addr marker apply only to global constants?
> 
> Anyway, thanks for the information.
> 
> -Quentin
> 
> On Feb 27, 2013, at 12:50 AM, Duncan Sands <baldrick at free.fr> wrote:
> 
>> Hi Quentin, you should only be merging them if they are marked with
>> unnamed_addr (this indicates that no-one is expecting the globals
>> to have distinct addressses).  As EH type infos shouldn't get
>> unnamed_addr, that should mean that the EH issue isn't a problem any
>> more.
>> 
>> Ciao, Duncan.
>> 
>>> You will find enclosed a patch that adds the support of constant variables for
>>> the generic global merge pass.
>>> I've also attached a motivating example, test.c.
>>> 
>>> In that file there are several global variables accessed within the same function.
>>> If all the variables are non-const, global merge generates one unique variable,
>>> which translates into one unique load in the assembly file.
>>> 
>>> clang -arch arm -O3 test.c -o - -S
>>> 
>>> If some are const (the example is very stupid), global merge does not merge
>>> anything and one load for each variable is issued, i.e., 3
>>> clang -arch arm -O3 test.c -o - -S -DWITHCONST
>>> 
>>> If global merge had merged the constant globals, only 2 loads would have been
>>> issued. The patch allows to do that.
>>> 
>>> Although the patch is fairly simple, it was not done before because it seems it
>>> was breaking the EH processing (see comment in the original code).
>>> Is it still true?
>>> 
>>> If yes, how could I reproduce that?
>>> 
>>> Note: that the patch disables by default the handling of global constants
>>> because the current heuristic may generate worse code. A tuning may be
>>> necessary, but it would be done as a second step
>>> 
>>> -Quentin
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130228/46735a1c/attachment.html>