Skip to content
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

Closed
lattner opened this issue Feb 4, 2007 · 10 comments
Closed

CBE can generate name conflicts #1536

lattner opened this issue Feb 4, 2007 · 10 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla miscompilation regression

Comments

@lattner
Copy link
Collaborator

lattner commented Feb 4, 2007

Bugzilla Link 1164
Resolution FIXED
Resolved on Feb 22, 2010 12:44
Version trunk
OS All

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 = *(&ltmp_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

@lattner
Copy link
Collaborator Author

lattner commented Feb 4, 2007

assigned to @isanbard

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 4, 2007

IIRC, the global/local patch was yours even though I committed it after getting
llvm-upgrade working. I would appreciate it if you could look into this as I am
behind on other tasks (the Shift thing set me back several days). If you don't
have time, this might have to wait a bit until I'm back on schedule. I have a
very important deadline happening in a few weeks .. can't miss it.

@lattner
Copy link
Collaborator Author

lattner commented Feb 5, 2007

btw, yes, I will do this, when I get time.

Thanks,

-Chris

@isanbard
Copy link
Contributor

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) {
%A = load i32
%var
%B = load i32* @​var;
%C = add i32 %A, %B
ret i32 %C
}

into:

unsigned int test(unsigned int *param_var) {
...
loc_A = *param_var;
loc_B = *(&gbl_var);
return (loc_A + loc_B);
}

This way, there is no ambiguity about what is local, global, or a parameter, there would be no name
conflicts, and it uses the original names.

-bw

@lattner
Copy link
Collaborator Author

lattner commented Feb 21, 2007

I think using a prefix for local names makes sense. How about "llvm_cbe_"? It could be used for any local
name (anything that is !isa) including params.

-Chris

@isanbard
Copy link
Contributor

So then in the example, it would be something like:

llvm_cbe_A = ...;
llvm_cbe_B = ...;

?

I'm wondering if there's still a problem with name conflicts between globals and locals. What if a global's
named "llvm_cbe_Foo" and the local's Foo also?

-bw

@lattner
Copy link
Collaborator Author

lattner commented Feb 21, 2007

So then in the example, it would be something like:
llvm_cbe_A = ...;

yep

I'm wondering if there's still a problem with name conflicts between globals and locals. What if a
global's
named "llvm_cbe_Foo" and the local's Foo also?

Just adding a unique prefix like this makes it less likely. To be extremely paranoid, the local symbols
should be picked and checked to see if they conflict with any global ones. If so, pick a different name.

-Chris

@isanbard
Copy link
Contributor

How about this?

unsigned int G = ((unsigned int )123);
unsigned int ltmp_0_1 = ((unsigned int )123);

unsigned int test(unsigned int *llvm_cbe_G) {
unsigned int llvm_cbe_A;
unsigned int llvm_cbe_B;

llvm_cbe_A = *llvm_cbe_G;
llvm_cbe_B = *(&ltmp_0_1);
return (llvm_cbe_A + llvm_cbe_B);
}

@lattner
Copy link
Collaborator Author

lattner commented Feb 22, 2007

looks great to me!

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla miscompilation regression
Projects
None yet
Development

No branches or pull requests

3 participants