moving to llvmdev.
It always amused me that we have
@a = weak global ...
but
@b = alias weak ...
I decided to dig why that is. The best I could find was
http://llvm.org/bugs/show_bug.cgi?id=1017#c15
Looking at some really old cold then suggests that the reason was that
the old bison based parser hard a reduction for alias linkages and
another one for global variable linkages. Putting the alias first
avoided the reduce/reduce conflict.
The days of the old .ll parser are long gone, but is it too late to
change? In case it is not, the attached patches implement just that
Cheers,
Rafael
llvm.patch (47.1 KB)
clang.patch (3.9 KB)
rebased patches attached.
llvm.patch (47.6 KB)
clang.patch (3.9 KB)
Looking at some really old cold then suggests that the reason was that
the old bison based parser hard a reduction for alias linkages and
another one for global variable linkages. Putting the alias first
avoided the reduce/reduce conflict.
Exactly
The days of the old .ll parser are long gone, but is it too late to
change? In case it is not, the attached patches implement just that
I'm afraid you need to provide syntax autoupgrade until 4.0
The days of the old .ll parser are long gone, but is it too late to
change? In case it is not, the attached patches implement just that
I'm afraid you need to provide syntax autoupgrade until 4.0
Why, we moved to doing autoupgrade via bitcode quiet some time ago.
There were quiet a few format changes to the .ll in the process.
Cheers,
Rafael
I'm afraid you need to provide syntax autoupgrade until 4.0
Why, we moved to doing autoupgrade via bitcode quiet some time ago.
There were quiet a few format changes to the .ll in the process.
I thought the policy was:
1. Provide bitcode autoupgrade until next LLVM release
2. Provide text autograde until next major LLVM release
I'm sure I may be wrong, though... There were precedents in the past -
you may want to look into them.
I thought the policy was:
1. Provide bitcode autoupgrade until next LLVM release
2. Provide text autograde until next major LLVM release
I'm sure I may be wrong, though... There were precedents in the past -
you may want to look into them.
I am sure we provide bitcode autougrade until the next major release,
since the bitcode reader is full of FIXME notes for 4.0.
We don't seem to provide text autoupgrade unless there a particular
demand for it. For example, when linkonce_odr_auto_hide was removed
all text parsing support for it went away in a single commit. For
linker_private we got upgrade support for it, but as a special case,
with a warning and we intend to drop it as soon as 3.5 branches.
Cheers,
Rafael
It seems kind of important to know what our compatibility promise is for the IR, since that is one of LLVM’s few places where there is some sort of compatibility guarantee.
I feel we should have it documented (in http://llvm.org/docs/DeveloperPolicy.html ?) so that it doesn’t slip like this.
Maybe this discussion is worth its own thread on llvmdev? I mean, we have two highly experienced developers in this thread with highly diverging opinions.
– Sean Silva