New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CBE can generate name conflicts #1536
Comments
assigned to @isanbard |
IIRC, the global/local patch was yours even though I committed it after getting |
btw, yes, I will do this, when I get time. Thanks, -Chris |
What would be a good strategy for naming variables? I could do something along these lines: @var = global i32 927 define i32 @test(i32 %var) { into: unsigned int test(unsigned int *param_var) { This way, there is no ambiguity about what is local, global, or a parameter, there would be no name -bw |
I think using a prefix for local names makes sense. How about "llvm_cbe_"? It could be used for any local -Chris |
So then in the example, it would be something like: llvm_cbe_A = ...; ? I'm wondering if there's still a problem with name conflicts between globals and locals. What if a global's -bw |
yep
Just adding a unique prefix like this makes it less likely. To be extremely paranoid, the local symbols -Chris |
How about this? unsigned int G = ((unsigned int )123); unsigned int test(unsigned int *llvm_cbe_G) { llvm_cbe_A = *llvm_cbe_G; |
looks great to me! |
Extended Description
Consider:
@G = global i32 123
@ltmp_0_1 = global i32 123
define i32 @test(i32 %G) {
%A = load i32 %G
%B = load i32* @ltmp_0_1
%C = add i32 %A, %B
ret i32 %C
}
The CBE generated code is:
unsigned int test(unsigned int *ltmp_0_1) {
...
ltmp_1_2 = *ltmp_0_1; // local
ltmp_2_2 = *(<mp_0_1); // global
return (ltmp_1_2 + ltmp_2_2);
...
This is a serious bug.
A not-as-serious bug: the CBE ignores the local names of symbols, turning %A into ltmp_1_2?
-Chris
The text was updated successfully, but these errors were encountered: