search for: privatelabelprefix

I'm working on an LLVM back end with output to assembly file (.s). I'm using the ARM assembly printer. The generated labels (e.g. for a while statement) start with '.' like .LBB0_1 I would like to change the '.' to something else (specifically $$ if it matters). I see a lot of customizability in targetinfo.cpp but not that particular item. Where should I be looking?

...., Triple) * MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add)...

...., Triple) * MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add)...

...., Triple) * MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add)...

...mInfo() o MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) o MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el o MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add)...

...., Triple) * MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add)...

...mInfo() o MipsMCAsmInfo::PointerSize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) o MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el o MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add)...

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because