search for: setendian

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

...elow). We're now processing the –EL option. At the moment, we substitute our mips-linux-gnu triple for a mipsel-linux-gnu triple, construct a Triple object from it and resolve the new Triple to a TargetTuple. But why do we need to bother with that kind of weird hackery when we can simply do Obj.setEndian(Little)? This is what Phase 7 of the plan is about. We end up with a cleaner way to process target changes that, until now, have required weird triple hacking to handle. I skipped the Triple -> TargetTuple resolution a moment ago and I should address that now. We already know that mapping Tripl...

> > The Triple object will remain unchanged. > > The Tuple will be the API to handle getting/setting parameters > depending on the Triple, compiler flags, attributes, etc. > > This part doesn't seem obvious from the direction the patches are going. > There will be no string representation of all options, as that would > be impossible, or at least, highly

...–EL option. At the >> moment, we substitute our mips-linux-gnu triple for a mipsel-linux-gnu triple, >> construct a Triple object from it and resolve the new Triple to a TargetTuple. >> But why do we need to bother with that kind of weird hackery when we can simply >> do Obj.setEndian(Little)? This is what Phase 7 of the plan is about. We end up >> with a cleaner way to process target changes that, until now, have required >> weird triple hacking to handle. > > This is something else I don't understand. Here is the first time you start > talking about AP...

...elow). We're now processing the –EL option. At the moment, we substitute our mips-linux-gnu triple for a mipsel-linux-gnu triple, construct a Triple object from it and resolve the new Triple to a TargetTuple. But why do we need to bother with that kind of weird hackery when we can simply do Obj.setEndian(Little)? This is what Phase 7 of the plan is about. We end up with a cleaner way to process target changes that, until now, have required weird triple hacking to handle. This is something else I don't understand. Here is the first time you start talking about APIs which is what I'm partic...

...elow). We're now processing the –EL option. At the moment, we substitute our mips-linux-gnu triple for a mipsel-linux-gnu triple, construct a Triple object from it and resolve the new Triple to a TargetTuple. But why do we need to bother with that kind of weird hackery when we can simply do Obj.setEndian(Little)? This is what Phase 7 of the plan is about. We end up with a cleaner way to process target changes that, until now, have required weird triple hacking to handle. This is something else I don't understand. Here is the first time you start talking about APIs which is what I'm partic...

...elow). We're now processing the –EL option. At the moment, we substitute our mips-linux-gnu triple for a mipsel-linux-gnu triple, construct a Triple object from it and resolve the new Triple to a TargetTuple. But why do we need to bother with that kind of weird hackery when we can simply do Obj.setEndian(Little)? This is what Phase 7 of the plan is about. We end up with a cleaner way to process target changes that, until now, have required weird triple hacking to handle. This is something else I don't understand. Here is the first time you start talking about APIs which is what I'm partic...

...elow). We're now processing the –EL option. At the moment, we substitute our mips-linux-gnu triple for a mipsel-linux-gnu triple, construct a Triple object from it and resolve the new Triple to a TargetTuple. But why do we need to bother with that kind of weird hackery when we can simply do Obj.setEndian(Little)? This is what Phase 7 of the plan is about. We end up with a cleaner way to process target changes that, until now, have required weird triple hacking to handle. This is something else I don't understand. Here is the first time you start talking about APIs which is what I'm partic...

...elow). We're now processing the –EL option. At the moment, we substitute our mips-linux-gnu triple for a mipsel-linux-gnu triple, construct a Triple object from it and resolve the new Triple to a TargetTuple. But why do we need to bother with that kind of weird hackery when we can simply do Obj.setEndian(Little)? This is what Phase 7 of the plan is about. We end up with a cleaner way to process target changes that, until now, have required weird triple hacking to handle. This is something else I don't understand. Here is the first time you start talking about APIs which is what I'm partic...

On 16 September 2015 at 21:56, Jim Grosbach <grosbach at apple.com> wrote: > Why do we care about GAS? We have an assembler. It's not that simple. There are a lot of old code out there, including the Linux kernel which we do care a lot, that only compiles with GAS. We're slowly moving the legacy code up to modern standards, and specifically some kernel folks are happy to move up

...elow). We're now processing the –EL option. At the moment, we substitute our mips-linux-gnu triple for a mipsel-linux-gnu triple, construct a Triple object from it and resolve the new Triple to a TargetTuple. But why do we need to bother with that kind of weird hackery when we can simply do Obj.setEndian(Little)? This is what Phase 7 of the plan is about. We end up with a cleaner way to process target changes that, until now, have required weird triple hacking to handle. This is something else I don't understand. Here is the first time you start talking about APIs which is what I'm partic...