<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Jakob,<br>
    <br>
    <div class="gmail_quote">2012/6/6 Jakob Stoklund Olesen <span
        dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank">stoklund@2pi.dk</a>></span><br>
      <blockquote class="gmail_quote" style="margin:0 0 0
        .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div class="im"><br>
          On Jun 6, 2012, at 2:53 AM, Ivan Llopard <<a
            href="mailto:ivanllopard@gmail.com">ivanllopard@gmail.com</a>>
          wrote:<br>
          <br>
          > We have a new BE for a VLIW-like processor and I'm
          currently working on<br>
          > instruction bundles. Ideally, I'd like to have bundles
          *before* RA to<br>
          > model certain constraints, e.g. the exposed one by
          Tzu-Chien a while ago<br>
          > in his thread<br>
          > <a
href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-September/004798.html"
            target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-September/004798.html</a><br>
          <br>
        </div>
        The bundle support in the tree should handle constraints like
        that. The register allocator basically sees bundles as single
        instructions when computing interference.<br>
        <div class="im"><br>
          > In order to build bundles, we have added a new bottom-up
          MIScheduler,<br>
          > right after reg coalescing, which behaves much like
          ScheduleDAGVLIW but<br>
          > without hazard recognizing. Due to some tricky
          instructions, we cannot<br>
          > schedule on the DAG. Bundles are built at exitRegion() in
          the scheduling<br>
          > process and the live interval information is updated
          correctly. After<br>
          > this, the RA is aware of bundles, at least from a
          LiveInterval point of<br>
          > view, and I had some problems regarding the
          rematerialization.<br>
          ><br>
          > AFAIK, the RA cannot remat if the target instruction is
          not the bundle's<br>
          > header.<br>
          > For this, I rather need a light bundle representation, or
          no bundle at<br>
          > all, so it can remat the right instruction with one
          condition: the<br>
          > remated location should preserve bundles. Nevertheless,
          for many other<br>
          > actions like LI splitting, the current representation
          works very well.<br>
          ><br>
          > In general, I want the RA to preserve bundles as well as
          to be able to<br>
          > model the constraint presented above in the thread.<br>
          > Should I fix the rematerialization code to look for the
          right<br>
          > instruction into the current bundle ?<br>
          > What's the direction you are following about instruction
          bundling ?<br>
          <br>
        </div>
        Remat is a problem because it breaks the abstraction of treating
        whole bundles as instructions. There are two issues:<br>
        <br>
        - Should we rematerialize the full bundle defining a value, or
        should we try to dig out the 'real' def inside the bundle?<br>
      </blockquote>
      <div><br>
        The second option is the preferred one for us. The remated
        instruction should create a new bundle which may be merged with
        other bundles later by custom passes. The same condition applies
        for copy insertions.<br>
        <br>
      </div>
      <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt
        0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
        <br>
        - After remat, we run dead code elimination in case the original
        def has no more uses. Again, should DCE erase a single
        instruction from inside a bundle, or should we erase the full
        bundle once all its defs are dead?<br>
      </blockquote>
      <div><br>
        In our particular case, the RA can freely remove instructions
        from a bundle without any special constraint. We don't need to
        wait till all defs inside a bundle are dead, which in some
        situations it may never happen.<br>
         </div>
      <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt
        0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
        <br>
        Ideally, I would like to treat the inside of a bundle like a
        black box that only the target understands. I am not too happy
        about erasing instructions inside bundles without some help from
        the target.<br>
        <br>
        How do you need remat to work?<br>
      </blockquote>
      <div><br>
        As described above.<br>
        <br>
        I understand your concern, other architectures may have stronger
        constraints or use bundles for other purposes (ARM?) which makes
        the task non-trivial.<br>
        We have a very particular VLIW architecture with complex
        operators but fewer constraints regarding the packet building
        and mangling. We need remat to work because spill is forbidden
        for a certain reg class.<br>
        <br>
        Do you plan to add more hooks in TargetLowering to remat?<br>
        <br>
         </div>
      <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt
        0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
        <span class="HOEnZb"><font color="#888888"><br>
            /jakob<br>
            <br>
          </font></span></blockquote>
    </div>
    <br>
    <br>
  </body>
</html>