> At first I thought this could be handled when lowering
loads and stores, but I realize that I can only catch the
targeted addresses of loads/stores here - however address
calculation nodes may occur anywhere in a DAG.
> So my first impulse would be to adjust the constants when
the GEP instructions are transformed to ADDs. Afaics his
would mean to change the TargetData class, which is not meant
to be subclassed.
> Is there a cleaner solution without modifying llvm?
> Regards, Christian
The XCore has loads / stores where the offset is scaled by the size of
the load or store. For example the load word instruction LDW takes an
offset which is multiplied by 4 and added to the base pointer. This is
dealt with in the patterns defined in XCoreInstrInfo.td. The following
pattern is used for LDW:
def : Pat<(load (add GRRegs:$addr, immUs4:$offset)),
(LDW_2rus GRRegs:$addr, (div4_xform immUs4:$offset))>;
thanks for your suggestion.
However, I think what you describe is what I meant by 'only catch
the targeted addresses of loads/stores', i.e. the address the instruction
is reading from/writing to.
However, if I have e.g. a chunk of code which stores the address of the second
element of struct str somewhere into another struct pstr:
%0 = getelementptr %struct.str* %s, i32 0, i32 1 ; <i16*> [#uses=1]
%1 = getelementptr %struct.pstr* %ps, i32 0, i32 5 ; <i16**> [#uses=1]
store i16* %0, i16** %1, align 4
Your suggestion allows to store the i32* at the right place in %struct.pstr, but
the first GEP instruction adds the size of the first element - in bytes! - of str to the
address of str to get the address of the second element. I need that size (aka offset)
to be in respect of 16bit.
(Note also that e.g. arbitrary pointer arithmetics could be done on %0 - when it comes
to lowering, we cannot know if an ADD node comes from a GEP or not)
Or to put it shortly, regarding the property of char being the smallest addressable piece
of data, sizeof(char) is 16 on my architecture, but "8" is hard coded in TargetData (maybe
'char' should rather be replaced by 'byte' in the last sentence).
Well my current workaround is just to divide offsets by 2 when resolving GEP instructions
but I still hope there is a good way to do this in the backend.
I think this would be to subclass TargetData in the backend - I'd appreciate if someone
could confirm or not that there isn't another option within the current way of designing
Thanks a lot,